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I.  INTRODUCTION 


A.  BACKGROUND 

In  early  1992,  the  Naval  Surface  Warfare  Center,  Port  Hueneme  Division  (NSWC 
PHD)  began  development  of  a  diagnostic  expert  system  that  would  assist  shipboard  fire 
control  technicians  in  troubleshooting  the  MK  92  Mod  2  Fire  Control  System  (FCS). 
Found  aboard  the  U.S.  Navy’s  Oliver  Hazard  Perry  class  of  guided  missile  fast  frigates, 
the  MK  92  Mod  2  FCS  is  based  on  1970’s  technology  and  has  evolved  into  a  costly  and 
difficult  system  to  maintain.  Outside  technical  assistance  is  often  required  by  the  ships  to 
troubleshoot  problems  with  the  MK  92  Mod  2  FCS. 

At  the  request  of  NSWC  PHD  engineers  in  late  1992,  Naval  Postgraduate  School 
(NPS)  faculty  and  graduate  students  joined  NSWC  PHD  in  their  efforts  to  develop  this 
expert  system  which  is  called  the  Maintenance  Advisor  Expert  System  (MAES).  This 
thesis  continues  the  research,  development,  and  implementation  efforts  involved  in  fielding 
MAES  to  the  fleet. 

The  development  and  fielding  of  MAES,  though  protracted  due  to  funding 
constraints,  could  not  come  at  a  more  opportune  time.  MAES  promises  to  improve  fault 
isolation,  reduce  reliance  on  overburdened  technical  representatives,  and  decrease 
unnecessary  replacement  of  perfectly  good  repair  parts.  (Powell,  1993)  All  of  these 
benefits  offer  considerable  leverage  to  shipboard  technicians  who  are  tasked  with 
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maintaining  a  system  that  will  receive  few  modifications  or  improvements  over  the 
system’s  remaining  useful  life. 

MAES  offers  shipboard  fire  control  technicians  a  powerful  tool  to  assist  them  in 
their  daily  efforts  to  support  MK  92  Mod  2  FCS.  However,  without  proper 
implementation,  MAES  could  very  easily  be  cast  aside  and  its  benefits  never  realized. 
Having  the  right  system  at  the  right  time  means  nothing  if  the  system  is  never  used. 

B.  OBJECTIVES 

The  objective  of  this  thesis  is  to  address  the  long-term  implementation  and 
deployment  issues  which  should  be  considered  prior  to  diffusion  of  MAES  to  applicable 
ships.  It  provides  a  three-tiered  implementation  plan  for  MAES.  The  plan  covers  MAES 
implementation  to  the  fleet,  integration  into  the  formal  training  pipeline,  and  transition  of 
life  cycle  support  to  the  Naval  Surface  Warfare  Center,  Port  Hueneme  Division  (NSWC 
PHD).  This  plan  could  serve  as  a  framework  for  future  implementation  projects  if  the 
MAES  concept  is  expanded,  and  expert  systems  are  developed  for  other  maintenance 
intensive  systems. 

C.  RESEARCH  QUESTIONS 

This  thesis  pursues  answers  to  three  primary  research  questions  which  are 
generally  analyzed  according  to  hardware,  documentation,  training,  and  support 
requirements. 

1.  What  are  the  implementation  issues  for  deploying  the  MK  92  Mod  2  FCS  MAES  to  all 
MK  92  Mod  2  Ships?  Specifically,  what  are  the  implementation  issues  with  respect  to: 

a.  Hardware  requirements 

b.  Documentation  requirements 
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c.  Training  requirements 

d.  Support  requirements/procedures 

2.  What  are  the  requirements  for  integrating  the  MK  92  Mod  2  FCS  MAES  into  the  MK 
92  Mod  2  "C"  School  curriculum  at  Fleet  Training  Center  (FTC),  San  Diego  and  Fleet 
Combat  Training  Center  (FCTC),  Dam  Neck?  Specifically,  what  are  the  implementation 
issues  with  respect  to: 

a.  Documentation  requirements 

b.  Hardware/Software  requirements 

c.  Course  materials  requirements 

3.  What  are  the  requirements  for  transitioning  life  cycle  support  for  the  MK  92  Mod  2 

FCS  MAES  software  to  NSWC  PHD?  Specifically,  what  are  the  implementation  issues 
with  respect  to: 

a.  Documentation  requirements 

b.  Hardware/Software  requirements 

c.  Training  requirements 

D.  SCOPE 

This  thesis  focuses  on  providing  (1)  an  implementation  and  deployment  plan  for 
installing  the  MK  92  Mod  2  FCS  MAES  aboard  all  MK  92  Mod  2  ships;  (2)  an  integration 
plan  for  incorporating  the  MK  92  Mod  2  FCS  MAES  into  the  MK  92  Mod  2  "C"  School 
curriculum  at  the  Fleet  Training  Centers;  and  (3)  a  transition  plan  for  shifting  life  cycle 
support  for  the  MK  92  Mod  2  FCS  MAES  software  to  NSWC  PHD. 

E.  ORGANIZATION  OF  THE  STUDY 


This  thesis  contains  six  chapters  and  six  appendices  which  are  organized  as 
follows: 
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Chapter  II,  Building  an  Implementation  Strategy,  discusses  the  implementation 
factors  and  the  risks  that  should  be  considered  when  developing  the  MAES  deployment 
plan. 

Chapter  m,  Deploying  MAES  to  all  MK  92  Mod  2  FCS  Ships,  details  the  long¬ 
term  implementation  plan  for  MAES.  The  chapter  covers  hardware,  documentation, 
training,  and  support  requirements  related  to  MAES’s  installation. 

Chapter  IV,  Integration  of  MAES  into  the  MK  92  Mod  2  FCS  “C”  School 
Curriculum,  discusses  the  on-going  relationship  between  the  Naval  Postgraduate  School 
(NPS)  and  the  Fleet  Training  Centers  (FTC)  with  regards  to  MAES  testing  and 
evaluation.  This  chapter  outlines  the  actions  required  to  formally  integrate  MAES  into  the 
MK  92  Mod  2  FCS  “C”  School  Curriculum. 

Chapter  V,  Transitioning  Life  Cycle  Support  for  MAES  to  NSWC  PHD,  describes 
the  documentation,  software/hardware  requirement,  training  requirements,  maintenance 
procedures,  and  annual  support  costs  associated  with  the  transfer  of  MAES  from  NPS  to 
NSWC  PHD. 

Chapter  VI,  Summary  and  Conclusions,  summarizes  the  author’s  conclusions 
regarding  the  long-term  implementation  issues  related  to  the  deployment  of  MAES.  The 
implementation  issues  are  discussed  within  the  framework  of  the  previously  described 
three-tiered  implementation  plan. 
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Appendix  A,  Fleet  Training  Center  Laboratory  Experiments  with  MAES,  provides 
a  description  of  the  evaluation  procedures  and  results  of  MAES  performance  tests 
conducted  at  Fleet  Training  Center,  San  Diego. 

Appendix  B,  Implementation  Plan  for  Deploying  MAES  to  all  MK  92  Mod  2  FCS 
Ships,  contains  the  implementation  plan  for  deploying  MAES  to  the  ships. 

Appendix  C,  Integration  Plan  for  Including  MAES  in  the  MK  92  Mod  2  FCS  “C” 
School  Curriculum,  describes  actions  required  to  formally  integrate  MAES  into  the 
MK  92  Mod  2  FCS  “C”  School  curriculum. 

Appendix  D,  MAES  System  Level  Description,  provides  a  preliminary  version  of 
one  of  the  four  documentation  requirements  needed  by  NSWC  to  maintain  MAES. 

Appendix  E,  Forms,  includes  forms  which  might  be  used  to  report  errors, 
recommend  changes,  or  seek  help. 

Appendix  F,  Software  Transition  Plan,  provides  a  standard  template  for  preparing 
software  transition  plans. 

Appendix  G,  Hardware,  Software,  and  Documentation  Requirements,  provides  a 
summary  of  anticipated  hardware,  software,  and  documentation  requirements  necessary  to 
field  MAES  to  ships,  integrate  it  into  the  “C”  school  curriculum,  and  transition  life  cycle 
support  for  it  to  NSWC  PHD. 


5 


6 


II.  BUILDING  AN  IMPLEMENTATION  STRATEGY 


A.  OVERVIEW 

Building  a  long-term  implementation  strategy  involves  several  steps.  First,  the 
risks  associated  with  the  project  must  be  identified.  Second,  those  factors  important  to  a 
successful  implementation  plan  must  be  targeted.  And  third,  an  implementation  plan 
should  be  developed  that  mitigates  the  risks  while  focusing  on  the  implementation  factors 
most  critical  to  success. 

This  chapter  begins  with  background  information  on  risk  management.  Next,  a 
risk  management  plan  for  deploying  MAES  is  discussed.  An  analysis  of  the  factors 
important  to  implementation  success  follows.  This  chapter  concludes  with  a  discussion  of 
how  implementation  factors  and  risks  should  be  incorporated  into  an  implementation  plan. 

B.  BACKGROUND  ON  RISK  MANAGEMENT 

Risk  management  is  not  a  new  discipline.  Its  origins  can  be  traced  back  as  far  as 
the  Babylonians,  to  around  3200  BC.  (Boehm,  1989)  Within  DoD,  risk  management 
gained  the  attention  of  Deputy  Secretary  of  Defense  David  Packard  in  1969  when  he 
wrote  that  inadequate  risk  assessment  was  a  major  problem  in  the  area  of  systems 
acquisition.  In  1986,  the  General  Accounting  Office  (GAO)  cited  deficiencies  in  the 
methodology  used  to  assess  technical  risk  within  25  program  offices.  GAO’s  review 
acted  as  the  catalyst  for  more  intense  consideration  of  risk  management  throughout  DoD. 
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(DSMC,  1989)  The  Naval  Doctrine  Publication,  Naval  Warfare,  also  emphasizes  the 
importance  of  effective  risk  management.  (NDP,  1994) 

Though  narrowly  applied  to  implementation  issues  in  the  case  of  MAES,  risk 
management  is  a  process  considered  more  broadly  in  areas  such  as  systems  acquisition, 
security  planning,  and  software  development.  (DSMC,  1989;  Rainer,  et  al,  1991)  DoD 
acquisition  policy  regulations  require  program  managers  to  continually  assess  program 
risks  and  emphasize  the  importance  of  understanding  risks.  (DoD  Directive  5000. 1, 1996) 
Even  with  a  small  project  such  as  MAES,  identifying  and  understanding  risks  can 
play  an  important  part  in  the  project’s  success.  Dart  and  Krasnov  (1995)  put  the 
importance  of  risk  management  (RM)  into  perspective: 

RM  is  a  key  to  successful  change.  It  provides  the  foundation  for  the 
deployment  team  to  make  the  right  kinds  of  decisions  when  introducing  change 
and  prioritizing  all  the  issues  that  need  to  be  addressed.  RM  is  a  pro-active  way  of 
fostering  positive  change.  It  enables  all  the  potential  users  of  the  new  solution  to 
get  involved  in  the  change  at  the  earliest  possible  time  and  contribute  their 
concerns  and  suggestions  for  risk  mitigation  strategies.  (Dart  and  Krasnov,  1995) 

The  terms  “risk”  and  “risk  management”  mean  different  things  to  different  people. 

As  a  result,  a  study  of  risk  and  risk  management  should  begin  by  defining  these  terms  as 

they  will  be  applied  to  MAES  implementation  issues. 

Risk  can  be  defined  as  “the  probability  of  an  undesirable  event  occurring  and  the 

significance  of  the  consequence  of  occurrence.”  (DSMC,  1989)  Expanding  this  definition, 

one  can  specify  three  key  elements  of  risk,  (1)  the  existence  of  an  event  that  can  cause 

change,  (2)  the  event  has  some  likelihood  of  occurrence,  and  (3)  the  event  has  some 

undesirable  consequence.  Based  on  this  expanded  definition,  risk  can  be  controlled  by 
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either  reducing  the  likelihood  that  a  certain  risk  event  will  occur  or  by  minimizing  the 
impact  of  the  event  should  it  occur,  or  both.  (Cleland,  et  al,  1993) 

Whether  approached  from  a  system  acquisition,  security,  or  software  project 
perspective,  risk  is  a  complex  concept  subject  to  individual  perception.  (DSMC,  1989; 
Rainer,  et  al,  1991)  Typically,  risk  is  characterized  by  the  fact  that  it  is  to  some  degree 
unknown,  it  changes  with  time,  and  it  is  manageable.  The  term  “risk  management” 
encompasses  the  processes  used  to  manage  risk.  (DSMC,  1989) 

Risk  management  is  “a  method  of  managing  that  concentrates  on  identifying  and 
controlling  the  areas  or  events  that  a  have  a  potential  for  causing  unwanted  change.” 
(Caver,  1985)  For  the  risk  management  process  to  work,  it  must  become  “formal, 
systematic,  and  applied  in  a  disciplined  manner.  (DSMC,  1989)  Different  approaches  for 
dealing  with  risk  are  offered  in  the  risk  literature.  (DSMC,  1989;  Boehm,  1989;  Cleland, 
et  al,  1993) 

The  various  approaches  or  structures  are  typically  very  similar  but  they  are  not 
connected  by  standard  terminology.  Using  different  definitions  to  describe  the  same  basic 
concepts  creates  confusion.  (DSMC,  1989)  To  avoid  miscommunication,  a  detailed 
description  of  expectations  should  be  outlined  prior  to  beginning  the  risk  management 
process.  (Cleland,  et  al,  1993)  Selecting  and  describing  a  risk  management  structure  will 
be  the  starting  point  for  the  MAES  risk  management  plan. 

The  risk  management  structure  provided  by  the  Defense  Systems  Management 
College  (DSMC)  and  illustrated  by  Figure  2-1  will  be  used  to  analyze  the  risks  associated 
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with  MAES’ s  implementation.  As  shown  in  Figure  2-1,  there  are  four  essential  activities 
associated  with  risk  management.  These  activities  include  risk  planning,  risk  assessment, 
risk  analysis,  and  risk  handling.  (DSMC,  1989) 


Figure  2-1.  Risk  Management  Structure  (From  DSMC,  1989) 


Planning  for  the  management  of  risk  aims  to  eliminate  risk  wherever  possible, 
isolate  and  minimize  risk,  develop  alternate  courses  of  action,  and  establish  a  strategy  for 
handling  those  risks  that  cannot  be  avoided.  (DSMC,  1989)  Research  has  shown  that 
most  software  disaster  projects  could  have  been  avoided  or  greatly  reduced  their 
problems,  “if  there  had  been  an  explicit  early  concern  with  identifying  and  resolving  their 
high-risk  elements.”  (Boehm,  1989) 

To  have  control  over  risk  it  is  necessary  to  be  fully  informed  about  the  risk  and  to 
have  thought  through  the  actions  required  to  eliminate,  minimize,  or  contain  the  effects  of 
undesirable  occurrences.  (Hannsson,  1989;  DSMC,  1989)  As  the  first  activity  in  the 
process,  risk  management  planning  forces  “formal,  systematic”  thought  about  the 
objectives  discussed  above.  (DSMC,  1989) 
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The  next  activity  is  risk  assessment  which  involves  two  steps.  The  first  step  is  risk 
identification  which  involves  identifying  the  significant  risks  and  then  describing  them  in  an 
understandable  way.  Techniques  such  as  expert  interviews  and  “lessons  learned” 
comparisons  are  used  in  the  assessment  phase  to  develop  narrative  statements  describing 
the  program  risks.  (DSMC,  1989) 

Preliminary  quantification  is  the  second  step  in  the  risk  assessment  phase.  The 
primary  purpose  of  this  step  is  to  prioritize  the  identified  risks  through  organization  and 
stratification.  Neither  the  risk  planning  phase  nor  the  risk  assessment  phase  requires  heavy 
mathematical  study;  however,  some  baseline  for  rating  risks  should  be  created  to  eliminate 
ambiguity.  A  simple  rating  scheme  is  preferred.  (DSMC,  1989) 

The  next  phase  of  risk  management  concerns  risk  analysis.  Difficult  to  clearly 
separate  from  the  risk  assessment  phase,  this  phase  involves  issues  such  as  the 
consequences  if  the  risk  becomes  reality  and  the  available  ways  of  dealing  with  it.  The 
most  useful  product  of  this  phase  is  a  risk  watchlist  which  acts  as  a  handy  tool  for  tracking 
risk  activities.  (DSMC,  1989) 

The  final  activity  in  the  risk  management  process  is  risk  handling  which  is  the 
process  of  taking  actions  to  mitigate  or  eliminate  the  unwanted  results  of  risk.  The  actions 
describing  risk  handling  techniques  can  be  categorized  as  avoidance,  control,  assumption, 
transfer,  and  knowledge  and  research.  (DSMC,  1989) 

Selecting  a  lower  risk  choice  from  several  alternatives  represents  a  risk  avoidance 
decision.  The  most  common  of  the  risk  handling  techniques,  risk  control  involves  the 
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continual  monitoring  and  adjustment  of  a  program  based  on  a  risk  reduction  plan.  While 
risk  assumption  represents  a  decision  to  accept  some  consequences,  risk  transfer  includes 
those  actions  taken  to  reduce  risk  exposure  by  sharing  the  risk  with  someone  else. 
(DSMC,  1989) 

Even  though  it  is  not  a  “true”  risk  handling  technique,  knowledge  and  research 
provides  information  in  support  of  the  other  techniques  and  serves  as  a  reminder  that  risk 
management  is  a  continual  process.  (DSMC,  1989)  The  risk  management  process  should 
be  viewed  as  a  continuous  loop  representing  a  never  ending  process.  (Cleland,  et  al, 
1993) 

C.  MAES  RISK  MANAGEMENT  PLAN 

The  MAES  risk  management  plan  will  generally  follow  the  risk  management 
structure  shown  in  Figure  2-1.  The  risk  planning  phase  will  not  be  specifically  addressed 
since  the  risk  management  background  discussion  adequately  covers  the  activities 
comprising  this  phase.  The  MAES  risk  management  plan  begins  with  the  risk  assessment 
phase. 

1.  Risk  Assessment 

Risk  assessment  involves  two  steps.  The  first  step  is  risk  identification  and  the 
second  step  is  preliminary  quantification. 

a.  Risk  Identification 

Risk  identification  requires  that  significant  risks  be  identified  and  described 
in  an  understandable  way.  Part  of  the  risk  identification  phase  involves  activities  such  as 
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expert  interviews  and  lessons  learned”  comparisons.  Risk  identification  was  begun  for 
the  MAES  project  by  discussing  “risks”  with  Susan  Dart  of  Continuus  Software,  an  expert 
in  the  field  of  software  configuration  risk  management.  “Lessons  learned”  comparisons 
were  derived  from  conversations  with  NSWC  Louisville  representatives,  U.S.  Army 
Research  Laboratory  engineers,  and  NAVSEA  engineers  about  their  respective 
experiences  with  expert  systems  implementations. 

Categorizing  the  risks  simplifies  the  process  of  risk  identification  and  will 
be  expanded  during  the  second  step  to  develop  a  risk  rating  scheme.  According  to  Dart 
(1996)  risks  can  be  grouped  into  three  categories  -  technical,  people,  and  organizational. 
Based  on  these  categories  we  identify  the  risks  associated  with  MAES  as  follows  (Dart 
and  Krasnov,  1995;  Dart,  1996): 


Technical  Risks  -  evolve  around  the  software  development  and 
maintenance  environment  and  the  structure  of  the  user’s  applications. 


•  Knowledge  Accuracy.  Knowledge  accuracy  concerns  the  domain  expert’s 
rendering  of  his  knowledge  in  a  manner  that  is  both  technically  accurate  and 
consistent  with  accepted  troubleshooting  practices. 

•  Maintainability.  Maintainability  risks  involve  how  easily  the  software  can  be 
updated  with  improvements  or  corrections  and  the  effort  required  to  keep  all 
versions  of  MAES  current. 

•  Software  Reliability/Quality/Availability.  This  multiple  risk  represents  the  need 
for  the  software  to  readily  provide  results  which  can  be  trusted  as  the  best 
possible  troubleshooting  solutions. 

•  Supportability.  Supportability  risk  has  two  dimensions,  one  internal  and  one 
external  to  the  MAES  project.  The  internal  supportability  risk  comes  from  the 
uncertain  budgetary  environment  surrounding  MK92.  The  external 
supportability  risk  comes  from  SoftSell,  the  software  company  that  created  the 
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expert  system  developmental  software  used  to  build  MAES.  If  SoftSell  drops 
support  of  this  software  or  goes  out  of  business  it  could  complicate  future 
supportability. 

•  Hardware  Durability  in  a  Shipboard  Environment.  Hardware  durability  is  a 
risk  because  of  the  numerous  harsh  elements,  such  as  electromagnetic 
interference  (EMI),  high  heat,  frequent  power  surges,  water,  and  corrosives, 
which  are  common  in  a  shipboard  environment.  Fielding  MAES  on  a 
commercial-off-the-shelf  (COTS)  laptop  computer  raises  the  risk  that  that  the 
COTS  laptop  will  be  too  fragile  for  a  shipboard  environment. 

•  Knowledge  and  Program  Documentation.  Knowledge  and  program 
documentation  risk  pertains  to  the  accuracy  and  completeness  of  the  written 
references  available  to  support  the  knowledge  represented  by  the  software  and 
the  format  of  the  underlying  software  development  program. 

•  Data  Gathering.  The  data  gathering  risk  stems  from  the  desire  to  collect  data 
after  MAES  is  fielded  to  illustrate  the  impact  of  MAES.  The  risk  comes  from 
historically  low  survey  response  rates  and  from  the  difficulty  in  selecting  a 
metric  which  can  quantitatively  reflect  MAES’s  impact. 

People  Risks  -  evolve  around  incorrect  expectations,  poor 
communications,  fear  and  lack  of  knowledge. 

•  Computer  Literacy.  This  risk  arises  from  the  possibility  that  some  of  the  Fire 
Control  (FC)  technicians  will  not  be  familiar  with  computers  and/or  the 
Windows®  environment. 

•  Technical  Representative  Resistance.  Driven  to  some  extent  by  perceptions, 
this  risk  encompasses  the  possibility  that  technical  representatives  (or  tech 
reps)  will  resist  this  technology  because  they  feel  that  MAES  challenges  their 
expert  authority  or  they  believe  that  MAES  is  designed  to  replace  them.  The 
very  limited  role  the  tech  reps  played  in  the  development  of  MAES  may  also 
contribute  to  their  resistance. 

•  Fire  Control  Technician  Resistance.  The  risk  from  the  FC’s  is  that  they  will 
not  freely  change  their  troubleshooting  paradigm  and  consequently  MAES  will 
not  be  used.  More  experienced  FC’s  may  be  committed  to  “the  way  it’s 
always  been  done”  or  they  may  simply  enjoy  the  challenge  of  isolating  faults  on 
their  own.  Additionally,  senior  FC’s,  who  have  always  relied  on  the  technical 


14 


manuals  or  technical  representatives  for  guidance,  may  not  trust  MAES  or 
encourage  its  use. 

•  Hierarchical  Resistance.  This  risk  deals  with  the  political  considerations 
inherent  in  the  Navy’s  hierarchical  structure  which  makes  individuals  sensitive 
to  seemingly  minor  issues  and  peripheral  concerns. 

•  Attitude  Towards  Change.  This  risk  weaves  through  every  element  of  this 
project  that  involves  people.  If  decision  makers  and  potential  users  of  MAES 
are  not  open  minded  about  the  possibilities  of  this  technology  then  this  project 
and  any  future  projects  that  might  advocate  this  technology  are  jeopardized. 

Organizational  Risks  -  evolve  around  organizational  politics  and  boundaries 
and  cultural  change. 

•  Chain-of-Command  Support.  This  risk  arises  because  the  Naval  Postgraduate 

School  (NPS)  operates  outside  of  the  chain-of-command  normally  associated 
with  fielding  production  level  systems  to  the  fleet.  In  dealing  with  the  various 
commands,  such  as  Naval  Sea  Systems  Command  (NAVSEA), 

COMNA V  SURFL  ANT,  COMNAVSURFPAC,  CINCLANTFLT, 

CINCPACFLT,  Fleet  Training  Center  (FTC),  San  Diego,  Fleet  Combat 
Training  Center  (FCTC),  Dam  Neck,  NSWC  PHD,  Fleet  Technical  Support 
Center,  Atlantic  (FTSCLANT)  and  Pacific  (FTSCPAC),  and  the  various  ships, 
the  MAES  deployment  team  must  establish  its  own  credibility  while 
concurrently  building  support  for  MAES.  The  risk  is  that  one  or  more  of  the 
commands  will  withhold  their  support  of  MAES  because  of  concerns  about  the 
program  or  NPS’s  role  in  the  development. 

.  •  Fleet  Training  Centers’  (FTC)  Acceptance  and  Adoption.  As  the  front-line 

trainers  of  FC  technicians,  the  FTC’s  create  the  students’  first  image  of  MAES. 
First  impressions  are  important.  Risk  arises  if  the  training  centers  do  not 
accept  and  readily  advocate  MAES  as  a  useful  troubleshooting  tool. 

•  Fleet  Technical  Support  Center  (FTSC)  Endorsement.  FTSC  representatives 
work  closely  with  the  ships  in  providing  troubleshooting  assistance  for  more 
complex  problems  and  generally  are  well-respected  for  their  technical 
expertise.  Because  of  their  role  as  technical  experts  who  work  closely  with 
shipboard  technicians,  they  pose  a  risk  to  MAES  if  they  do  not  endorse  it  as  a 
viable  troubleshooting  tool.  If  they  do  not  accept  MAES  then  it  is  unlikely  that 
shipboard  technicians  will  trust  the  system. 
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•  System  Use  by  Fire  Control  Technicians.  This  risk  lies  with  the  older,  more 
experienced  FC’s  who  may  not  trust  MAES  or  may  feel  that  they  do  not  need 
MAES.  Negative  attitudes  on  the  part  of  experienced  FC’s  may  create 
sufficient  pressure  to  keep  junior  FC’s  from  using  MAES. 

•  MAES  Deployment  Training.  The  transient  nature  of  Navy  personnel 
combined  with  ship  deployments  create  the  risk  that  personnel  will  not  receive 
proper  MAES  training. 

•  Deployment  Funding.  While  MAES  is  funded  through  evaluation  at 
COMNAVSURFLANT,  funding  for  deployment  is  not  a  certainty. 
Deployment  funding  will  include  funding  to  field  MAES  -  (computers  and 
training),  funding  to  transition  MAES  to  the  Post-Deployment  System  Support 
(PDSS)  activity  and  the  FTC’s,  and  funding  to  rework  the  evaluation  software 
to  a  production  system. 

b.  Preliminary  Quantification 

Preliminary  quantification  is  the  second  step  in  the  risk  assessment  phase. 
The  primary  purpose  of  this  step  is  to  prioritize  the  identified  risks  through  a  simple  rating 
scheme.  The  rating  scheme  for  the  deployment  of  MAES  contains  four  risk  classifications 
which  are  described  below: 

•  Class  I:  Event  poses  a  minor  threat  to  the  success  of  MAES.  Little 
management  attention  is  necessary  to  overcome  this  risk. 

•  Class  II:  Event  poses  a  moderate  threat  to  the  success  of  MAES.  Active 
management  attention  and  monitoring  is  required  to  overcome  this  risk. 

•  Class  III:  Event  poses  a  significant  threat  to  the  success  of  MAES.  Close 
management  attention  and  monitoring  is  required  to  overcome  this  risk. 
Improper  treatment  of  this  risk  could  jeopardize  the  project. 

•  Class  IV:  Event  poses  an  extreme  threat  to  the  success  of  MAES.  Regardless 
of  management  attention,  the  occurrence  of  this  event  will  jeopardize  the 
project. 
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In  applying  these  risk  classifications  to  the  applicable  events  the 
consequence  of  occurrence  has  been  incorporated  into  the  classification  while  the 
likelihood  of  occurrence  will  be  subjectively  considered  as  the  specific  events  are 
classified.  Table  I  illustrates  the  results  of  subjectively  rating  each  risk  on  a  scale  of  one  to 
five,  one  being  low  and  five  being  high,  for  the  risk  elements,  likelihood  of  occurrence  and 
consequences  of  occurrence.  Ratings  were  determined  based  on  interviews,  historical 
trends,  and  risk  literature.  By  no  means  scientific,  the  purpose  of  this  classification 
scheme  is  merely  to  provide  a  method  for  organizing  risks. 

Based  on  the  combined  risk  elements’  scores  shown  in  Table  I,  risks  are 
classified  as  either  Class  I,  II,  III,  or  IV  risks.  Class  I  risks  are'  those  risks  with  combined 
risk  elements’  scores  between  three  and  five.  Class  H  risks  are  those  risks  with  combined 
risk  elements’  scores  of  six  or  seven.  Class  ffl  risks  are  those  risks  with  combined  risk 
elements  scores  of  eight  or  nine.  Class  IV  risks  are  those  risks  with  combined  risk 
elements’  score  often.  Table  II  summarizes  the  risk  classifications.  Note  that  no  class  IV 
risks  exist  for  MAES.  Also  note  that  even  though  there  are  more  technical  risks  than 
people  or  organizational  risks,  the  risk  classification  results  show  that  more  managerial 
attention  should  be  focused  on  the  people  and  organizational  issues. 

As  an  overview  of  how  ratings  were  assigned  to  the  risk  elements  consider 
the  following  examples.  Hardware  durability,  a  Class  I  risk,  received  a  likelihood  of 
occurrence  score  of  one  and  a  consequences  of  occurrence  score  of  four  for  a  combined 
risk  elements’  score  of  five.  While  numerous  harsh  elements  found  in  the  shipboard 
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environment  threaten  COTS  equipment,  personal  experience  has  shown  that  COTS 
computers  are  far  more  durable  than  one  would  expect  and  thus  the  likelihood  of  this  risk 
occurring  is  minimal.  Alternatively,  if  the  risk  does  occur,  meaning  the  hardware  is 
unreliable,  the  consequences  will  be  severe. 

Fire  Control  Technician  resistance,  a  Class  II  risk,  received  a  likelihood  of 
occurrence  score  of  two  and  a  consequences  of  occurrence  score  of  four  for  a  combined 
risk  elements’  score  of  six.  Feedback  received  from  fire  controlmen  at  FTC,  San  Diego, 
and  aboard  the  MAES  prototype  test  ship,  reveals  that  sailors  will  be  receptive  to  MAES 
which  indicates  that  the  likelihood  of  occurrence  for  this  risk  is  small.  If  the  risk  does 
occur  the  consequences  could  be  severe  since  resistance  would  equate  to  non-use  of 
MAES. 

Chain-of-Command  support,  a  Class  m  risk,  received  a  likelihood  of 
occurrence  score  of  three  and  a  consequences  of  occurrence  score  of  five  for  a  combined 
risk  elements’  score  of  eight.  At  least  ten  different  commands,  including  several  different 
departments  within  a  few  of  the  commands,  will  be  involved  in  the  deployment  of  MAES. 
The  large  number  of  individuals  and  commands  representing  their  own  interests  creates  a 
likelihood  that  one  or  more  of  the  commands  will  withhold  full  support  of  MAES.  If  this 
occurs  support  from  other  commands  may  fall  like  dominoes. 

As  a  possible  scenario,  suppose  that  either  the  Fleet  Combat  Training 
Center  (FCTC),  Dam  Neck  or  the  Fleet  Technical  Support  Center  (FTSC),  Atlantic  does 
not  fully  support  MAES.  Without  the  endorsement  of  FCTC  and/or  FTSC, 
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COMNAVSURFLANT  would  probably  withdraw  their  sponsorship  of  MAES.  Risk 
literature  clearly  specifies  that  full  management  support  is  required  for  implementation 
success.  If  MAES  does  not  receive  full  chain-of-command  support  the  consequences 
could  be  devastating.  (Bradley  and  Hauser,  1995) 

With  more  experience  implementing  expert  systems,  it  might  be  desirable 
to  develop  risk  templates  that  define  risk  areas  and  the  likelihood  and  consequence  of 
risks’  occurrence  based  on  past  experience.  McDonnell  Douglas  Aerospace  uses  such  an 
approach  to  develop  risk  templates  that  can  be  applied  to  common  risks  among  different 
software  projects.  The  templates  are  used  to  assign  a  value  of  low,  minor,  moderate, 
significant,  or  high  to  the  likelihood  and  consequence  of  occurrence  for  each  risk.  These 
values  are  entered  into  a  two-dimensional  matrix  to  determine  the  risk  level.  By  relying  on 
past  experience,  this  approach  removes  some  of  the  subjectivity  inherent  in  determining 
risk  levels.  (Mason  and  Boyd,  1995) 

2.  Risk  Analysis 

Issues  such  as  the  consequences  if  the  risk  becomes  reality  and  the  available  ways 
of  dealing  with  it  are  tackled  during  the  risk  analysis  phase.  Using  the  risk  classifications 
from  Table  II,  risks  requiring  the  most  resources  are  discussed  first.  Due  to  time  and 
funding  constraints  risk  prioritization  is  necessary  so  that  efforts  can  be  focused  on  the 
areas  that  provide  the  greatest  return. 
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Risk  Elements 
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FTSC  Endorsement 

3 
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3 

5 
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4 

4 
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3 

5 

8 

Table  I.  MAES  Risk  Element  Ratings 
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Table  n.  MAES  Risk  Classification  Table 
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Class  HI  Risks: 


•  Technical  Representative  (Tech  Rep)  Resistance.  Already  a  reality  to  some 
extent,  tech  rep  resistance  remains  a  volatile  issue.  Several  tech  reps  at  both 
FTSCLANT  and  FTSCPAC  are  skeptical  of  MAES  because  it  professes  to 
perform  skills  similar  to  their  own  yet  they  were  largely  excluded  from  the 
initial  MAES  development  process. 

If  MAES  proves  itself  on  the  ships  then  this  risk  can  be  expected  to 
gradually  erode;  however,  if  MAES  turns  out  to  be  riddled  with  errors  or 
controversial  procedures,  tech  rep  resistance  will  likely  solidify  against  MAES. 
If  tech  rep  resistance  grows  then  fleet  use  of  MAES  will  probably  suffer  and 
future  support  for  MAES  will  diminish. 

The  best  way  to  counter  this  risk  is  to  establish  open  and  honest 
communications  with  the  FTSC  tech  reps.  As  important  links  to  the  fleet,  tech 
reps  should  be  aggressively  pursued  for  their  opinions  of  MAES.  Whether 
positive  or  negative,  their  comments  are  valuable.  Their  criticisms  can  be  used 
to  improve  MAES  and  their  positive  comments  will  help  MAES  gain  fleet 
acceptance. 

In  addition,  seeking  the  active  involvement  of  the  tech  reps  in 
expanding  the  knowledge  of  MAES  would  include  them  as  part  of  the 
development  process.  This  could  significantly  reduce  their  resistance  to 
MAES.  Long-term,  the  tech  reps  could  become  the  best  source  for  updates 
and  changes  to  MAES. 

•  Hierarchical  Resistance.  Minor  issues  or  peripheral  considerations  may  heavily 
impact  the  way  that  MAES  is  eventually  implemented.  Sensitivity  to  the 
special  concerns  of  all  involved  activities,  even  those  just  remotely  involved, 
will  be  important  during  the  early  implementation  stages.  Should  someone  feel 
that  they  have  not  been  properly  informed  on  some  matter  the  entire 
implementation  effort  could  be  stalled  and  further  support  could  be 
jeopardized. 

As  one  example,  an  early  conversation  about  implementation  issues 
with  a  CINCLANTFLT  representative  indicated  that  CINCLANTFLT  was  not 
familiar  with  the  MAES  project  and  should  be  fully  informed  prior  to  fielding 
the  system  to  any  east  coast  ships.  Another  conversation  with  a  FTSC 
representative  indicated  concerns  about  the  accuracy  of  MAES.  This  concern 
surfaced  during  casual  conversation  and  could  have  easily  gone  unvoiced.  Its 
ramifications  are  potentially  very  serious. 

This  risk  can  be  handled  by  first  identifying  all  commands  that  might 
have  an  interest  in  MAES.  These  commands  should  be  kept  informed  about  the 
project  and  periodically  solicited  for  comments  and  concerns. 
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•  Chain-of-Command  support.  NAVSEA,  FCTC  Dam  Neck,  FTC,  San  Diego 
FTSCLANT,  FTSCPAC,  CINCLANTFLT,  CEMCPACFLT,’ 
COMNAVSURFLANT,  COMNAVSURFPAC,  NSWC  PHD,  and  the  various 
ships  are  all  players  in  the  fielding  of  this  system.  Each  command  has  its  own 
expectations  of  MAES.  When  MAES  software  development  and  fielding 
studies  migrated  from  NSWC  PHD  to  the  Naval  Postgraduate  School  (NPS)  a 
paradigm  shift  occurred. 

Internally,  little  changed;  but  externally  the  shift  created  new 
relationships  founded  on  unfamiliar  turf.  The  type  commanders’  staffs,  the 
technical  support  commands,  and  even  the  training  centers  were  familiar  with 
NAVSEA  and  NSWC  and  understood  their  relationship.  Since  NPS  rarely 
develops  production  level  systems  our  involvement  has  created  a  new  inlet  to 
an  old,  well-established  pipeline. 

This  situation  creates  risks  which  may  have  been  resolved  long  ago 
between  the  established  players  but  resurface  as  the  MAES  development  team 
attempts  to  build  support  and  enthusiasm  for  the  system.  If  one  or  more  of 
these  commands  withholds  support  for  MAES,  the  project  could  be  placed  in 
jeopardy. 

One  way  to  counter  this  risk  is  to  more  actively  associate  the  project 
with  NSWC  PHD  instead  of  NPS.  With  NPS  as  the  software  developer, 
individuals  from  various  commands  might  silently  wonder  where  NPS  gets  the 
technical  expertise  to  be  involved  in  the  MAES  project.  While  this  seems 
absurd  to  someone  with  full  information  about  the  MAES  effort,  it  may  seem 
like  a  completely  valid  concern  to  someone  with  limited  knowledge  about 
MAES.  Silent  concerns  like  these  pose  a  significant  risk  but  can  be  overcome 
b>'  aggressive  marketing  and  education.  Presentations  should  discuss  the  roles 
of  NAVSEA,  NSWC  PHD,  and  NPS. 

•  FTSC  Endorsement.  This  is  perhaps  the  most  influential  risk  of  the  entire 
project.  This  organizational  risk  is  closely  coupled  to  the  people  risk,  tech  rep 
resistance,  discussed  above.  Without  FTSC  acceptance,  adoption,  and 
advocacy,  it  is  unlikely  that  the  sailors  will  assimilate  MAES  into’  their 
troubleshooting  repertoire.  This  will  occur  for  at  least  two  reasons. 

First,  if  the  FTSCs  do  not  accept  MAES,  then  other  commands,  such  as 
the  type  commanders,  might  be  reluctant  to  fully  support  MAES.  Second,  if 
the  FTSCs  do  not  endorse  MAES,  sailors  may  be  reluctant  to  use  the  system. 


•  System  Use  by  FC’s.  The  risk  lies  with  the  older  more  experienced  FC’s  who 
may  not  trust  MAES  or  may  feel  that  they  do  not  need  MAES.  Negative 
attitudes  on  the  part  of  experienced  FC’s  may  create  sufficient  pressure  to  keep 
junior  FC’s  from  using  MAES.  If  this  risk  becomes  reality  then  the  benefits  of 
MAES  will  never  be  realized. 
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The  most  effective  way  to  deal  with  this  risk  is  to  aggressively  build 
support  throughout  the  chain-of-command  by  emphasizing  the  many  benefits 
of  MAES.  Gaining  FTSC’s  endorsement  of  MAES  also  reduces  the  risk.  The 
most  effective  way  to  mitigate  both  the  FTSC  endorsement  and  the  system  use 
risks  would  be  for  the  FTSC  representatives  to  ask  sailors  if  they  used  MAES 
prior  to  calling  for  assistance. 


•  MAES  Deployment  Training.  Much  effort  will  be  focused  on  providing  quality 
training  to  each  ship  as  MAES  is  introduced.  Unfortunately,  due  to  the 
transient  nature  of  shipboard  personnel,  much  of  this  training  may  not  be 
passed  on  to  newcomers  who  might  have  been  transferred  from  a  command 
without  MAES  or  deployed  during  the  MAES  fielding.  As  the  FC’s  with 
MAES  experience  and  training  transfer,  the  “corporate”  knowledge  about  how 
to  use  MAES  may  lapse. 

To  decrease  this  risk,  MAES  deployment  training  must  be  designed  so 
that  it  perpetuates  itself.  Simply  providing  initial  implementation  training  and 
then  including  MAES  training  in  the  work  center’s  training  plan  may  be 
inadequate  to  ensure  that  MAES  training  and  experience  are  passed  down  to 
remaining  technicians  as  others  transfer. 

To  ensure  system  use  and  to  encourage  ongoing  training,  some  expert 
systems  have  been  listed  as  tools  to  be  used  during  routine  Preventive 
Maintenance  System  (PMS)  checks,.  (Pandit,  1996)  Another  solution  might 
be  to  require  Casualty  Report  (CASREP)  comments  concerning  the  use  or 
non-use  of  MAES. 

•  Deployment  Funding.  Deployment  funding  risk  arises  if  after  the  evaluation 
period  funding  is  not  forthcoming  to  deploy  the  production  version  of  MAES. 
Without  adequate  deployment  funding,  the  MAES  project  will  end,  depriving 
the  fleet  of  a  valuable  troubleshooting  tool. 

An  effective  marketing  campaign  that  emphasizes  the  benefits  and  cost 
sayings  of  MAES,  while  highlighting  the  results  from  evaluation  tests  of  the 
calibration  module  at  FTC,  San  Diego,  provides  the  best  approach  for  handling 
this  risk.  This  project’s  long  history  of  austere  funding  suggests  that 
deployment  funding  will  be  obtained  only  after  great  expenditure  of  time  and 
effort.  Optimistic  hope  is  the  only  thing  preventing  deployment  funding  from 
being  a  Class  IV  risk. 

Class  II  Risks: 

•  Knowledge  Accuracy.  Due  to  the  complexity  of  the  knowledge  contained  in 
MAES,  it  is  likely  that  there  will  be  errors.  Even  without  errors,  different 
experts  will  propose  different  ways  to  accomplish  the  same  tasks.  The 
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consequences  of  knowledge  inaccuracies  depend  on  the  frequency  and 
seriousness  of  the  discrepancies.  Numerous  minor  problems  or  a  few  serious 
problems  could  jeopardize  the  program’s  credibility  and  greatly  frustrate  users 
especially  if  feedback  channels  are  not  responsive  to  problem  reports. 

This  risk  can  be  minimized  by  encouraging  close  scrutiny  of  MAES 
during  the  prototype  phase.  In  the  long-term,  this  risk  should  be  dealt  with  by 
establishing  responsive,  user-friendly  feedback  channels  connecting  all  MAES 
users. 

A  configuration  management  board,  comprised  of  representatives  from 
NSWC  PHD,  FTSCLANT,  and  FTSCPAC,  could  be  convened  on  an  semi¬ 
annual  or  annual  basis  to  groom  the  MAES  program.  With  NSWC  PHD  as  the 
coordinator,  e-mail  between  the  board  members  could  support  an  ongoing 
dialogue  about  MAES. 

•  Maintainability.  Identified  as  one  of  the  elements  which  killed  off  expert 
systems,  maintainability  problems  could  cripple  MAES  if  the  system  becomes 
either  too  expensive  or  too  time  consuming  to  maintain.  (Davenport,  1995) 
Maintainability  applies  to  the  time,  effort,  and  expense  required  to  keep  the 
expert  system  software  updated  with  the  changes  pertinent  to  all  of  the  various 
versions  for  different  equipment  configurations. 

Fortunately,  the  maintainability  risk  has  already  been  mitigated  by 
several  factors.  First,  MAES  has  been  designed  with  maintainability  in  mind 
Multi-media  features,  such  as  videos,  were  not  incorporated  into  MAES 
because  of  the  time  and  expense  required  to  update  them. 

Second,  MK  92  Mod  2  FCS  is  expected  to  have  few  modifications  to 
the  system.  This  greatly  reduces  the  potential  software  maintenance  tasks  by 
effectively  restricting  maintenance  issues  to  the  program  as  fielded. 

Third,  the  graphical  displays  developed  with  the  expert  system 
developmental  shell  closely  resemble  the  structure  of  the  knowledge 
documentation  provided  by  the  domain  expert.  These  close  ties  make  it  easier 
for  someone  performing  maintenance  to  correlate  program  changes  with 
supporting  software  documentation. 

Last,  the  modular  design  of  MAES  simplifies  maintenance  by  limiting 
the  scope  of  the  updates  or  corrections.  Beyond  these  considerations, 
maintainability  risk  can  be  decreased  by  ensuring  that  the  fielded  system’s 
annual  maintenance  budget  is  adequately  funded.  NPS  estimates  annual  life- 
cycle  support  costs  at  $50,000  to  $100,000. 


•  Software  Reliability/Quality/Availability.  If  software  reliability,  quality  and/or 
availability  becomes  a  problem  then  MAES  will  likely  be  discarded  by  sailors 
as  they  lose  trust  in  the  system.  Measures  such  as  prototype  evaluations, 
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independent  validation  and  verifications,  and  reasonable  developmental 
scheduling  have  been  employed  to  diminish  this  risk. 

Feedback  from  the  prototype  version,  which  has  been  in  use  by  several 
activities  for  over  a  year,  indicates  that  the  reliability/quality/availability  risk 
may  be  minimal.  As  more  activities  begin  to  use  MAES  on  a  more  frequent 
basis,  this  risk  could  increase. 

If  feedback  shows  that  this  risk  is  increasing,  then  aggressive  steps 
should  be  taken  to  publicize  known  problems  and  to  provide  timely 
corrections.  As  Intel  learned  from  their  Pentium®  chip  error  fiasco,  even 
minor  problems  can  explode  into  damaging  episodes  if  not  properly  handled. 

•  Fleet  Training  Center  Acceptance  and  Adoption.  An  important  link  to  the  fleet 
will  be  jeopardized  if  this  risk  becomes  reality.  Much  has  already  been  done  to 
mitigate  this  risk.  FTC  San  Diego  continues  to  be  an  active  participant  in  this 
project  which  provides  sailors  with  very  early  exposure  to  MAES. 

Some  risk  still 

exists  here  since  FCTC  Dam  Neck  has  only  recently  begun  working  with 
MAES.  Failure  to  win  FCTC  Dam  Neck’s  endorsement  could  be  a  fatal  blow 
to  the  MAES  project  since  the  training  center  will  be  one  of  the  activities  to 
which  SURFLANT  looks  for  input  about  MAES. 

Close  liaison  should  continue  with  the  training  centers  to  ensure  that 
any  concerns  they  have  about  MAES  are  properly  addressed.  Since  the 
training  centers  offer  junior  FC’s  their  first  exposure  to  MAES,  they  are  in  an 
ideal  position  to  identify  problems  that  first  time  users  of  MAES  might  have. 

•  Fire  Control  Technician  Resistance.  For  this  risk  to  pose  a  serious  threat  to 
MAES,  other  factors  such  as  lack  of  support  from  the  chain-of-command  or 
poor  FTSC  acceptance  would  have  to  occur.  Given  that  MAES  performs  as 
advertised  and  absent  any  negatively  contributing  factors,  this  risk  could  be 
expected  to  gradually  diminish  as  positive  information  from  the  users  of  MAES 
spreads  to  others. 

The  timesaving  aspects  of  MAES  should  be  discussed  during 
implementation  training.  One  of  the  few  incentives  available  to  motivate 
sailors  is  liberty.  If  MAES  saves  them  time,  they  will  use  it. 

•  Attitude  Towards  Change.  This  risk  ties  into  the  other  risks  concerning 
resistance  but  provides  a  more  general  approach  to  the  problem.  Though 
seemingly  trivial,  people’s  attitudes  towards  change  can  pose  a  significant  risk 
to  this  project.  The  best  way  to  deal  with  this  risk  is  to  include  a  plan  for 
facilitating  change  in  the  implementation  strategy. 
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Class  I  Risks: 


•  Supportability.  Uncertainty  surrounds  the  supportability  of  MAES  both 
because  of  the  volatile  nature  of  many  software  companies  and  because  of  the 
decreased  funding  and  billets  assigned  to  support  MK  92. 

There  are  no  assurances  that,  SoftSell,  the  company  that  designed  the 
expert  system  shell  will  continue  to  support  their  older  products.  If  this  risk 
arises  then  MAES  may  become  locked  into  the  Windows®  3.1  or  Windows 
95®  operating  environment  where  over  time  software  problems  may  be 
identified  but  are  unrepairable. 

Similarly,  there  are  no  guarantees  that  NSWC  will  have  the  software 
personnel  to  support  MAES  in  the  long-term. 

Depending  on  the  effort  required  to  support  MAES,  there  may  not  be  adequate 
funding  to  fully  support  MAES  ’ s  upkeep. 

The  risk  with  SoftSell  should  be  dealt  with  by  obtaining  all  available 
information  and  documentation  about  the  developmental  tool  from  SoftSell 
and  by  vigorously  tracking  all  trouble  reports  submitted  to  them.  The  risk  with 
NSWC  support  can  be  decreased,  but  not  eliminated,  by  ensuring  that  MAES 
maintenance  is  included  in  the  tasking  for  overall  MK  92  support. 

•  Hardware  Durability.  If  COTS  laptops  prove  to  be  too  fragile  for  the  harsh 
elements  found  in  a  shipboard  environment,  then  MAES  users  could  become 
prejudiced  against  MAES  based  on  hardware  problems  rather  than  software 
performance.  In  short,  frustration  with  the  hardware  could  lead  to  non-use. 

This  risk  might  be  diminished  by  fielding  MAES  on  ruggedized 
computers.  While  ruggedized  computers  might  be  more  durable  than  COTS 
computers,  especially  in  a  shipboard  environment,  the  high  cost  of  ruggedized 
computers  might  be  prohibitive  for  the  activity  that  funds  MAES’s  deployment. 

One  alternative  approach  would  be  for  the  In-service  Support 
Engineering  Activity  (ISEA),  NSWC  PHD,  to  purchase  replacement  COTS 
laptops  with  funds  that  would  have  been  used  for  ruggedized  computers.  This 
would  allow  for  a  phased  replacement  type  of  laptop  purchase  rather  than  a 
one-time  expenditure  for  ruggedized  computers  that  may  be  no  more  reliable 
than  COTS  computers.  As  the  failure  rate  of  the  COTS  laptops  becomes 
known  then  additional  replacement  computers  could  be  purchased.  Based  on 
personal  experience,  COTS  laptops  will  prove  to  be  far  sturdier  than  one 
would  expect. 

The  intent  of  this  approach  would  be  to  ensure  that  hardware  problems 
do  not  jeopardize  the  successful  deployment  of  MAES.  This  would  not  be  a 
long-term  commitment  on  the  part  of  the  ISEA.  After  an  introductory  period 
of  six  to  nine  months,  hardware  maintenance  responsibilities  would  shift  to  the 
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ships.  The  fielding  plan  calls  for  the  laptops  to  be  designated  as  test  equipment 
with  replacement  responsibilities  residing  with  the  ships. 

•  Documentation.  This  risk  ties  not  only  to  short-term  program  accuracy  but 
also  to  long-term  maintainability.  Without  adequate  documentation,  MAES 
will  be  difficult  to  update/upgrade  which  will  hinder  life  cycle  support  efforts. 

The  most  desirable  way  to  deal  with  this  risk  is  to  ensure  that  adequate 
documentation  exists  before  the  MAES  software  is  transitioned  to  NSWC. 
Documentation  is  discussed  in  Chapter  V  of  this  paper. 

•  Data  Gathering.  If  data  gathering  materializes  as  a  risk,  it  could  affect  future 
MAES  enhancements  or  the  development  of  other  expert  systems,  as  benefits 
of  the  system  will  be  hard  to  prove. 

An  inexpensive  way  to  deal  with  this  risk  would  be  to  have  thesis 
students  analyze  MK  92  Mod  2  maintenance  data  before  and  after  MAES. 
Another  method  would  be  to  look  at  repair  parts  demand  information  for  MK 
92  Mod  2  before  and  after  MAES  implementation.  Repair  parts  demand 
information  is  available  from  the  Naval  Inventory  Control  Point  (NAVTCP), 
Mechanicsburg,  Pennsylvania. 

•  Computer  Literacy.  While  FC’s  are  some  of  the  most  technically  oriented 
people  on  a  ship,  there  are  no  guarantees  that  they  will  all  feel  comfortable 
using  a  computer.  If  some  of  the  FC’s  feel  uncomfortable  using  the  computer, 
MAES  use  may  suffer  or  the  tool  may  be  monopolized  by  those  FC’s  familiar 
with  computers. 

The  ways  to  counter  this  risk  are  to  provide  brief  computer  training 
during  implementation  training  and  to  include  explicit  instructions  in  the  users’ 
manual  about  computer  basics.  Over  time  this  risk  will  diminish  as  new  MK 
92  Mod  2  FCS  “C”  school  graduates,  who  have  received  introductory 
computer  training  at  one  of  the  fleet  training  centers,  reach  the  fleet. 

Review  of  the  above  risks  and  their  classifications  reveals  that  many  of  the 
risks,  especially  Class  III  risks,  are  highly  interdependent.  They  are  interdependent  in 
terms  of  how  they  should  be  handled  and  in  that  success  or  failure  in  one  area  can  lead  to 
a  similar  outcome  in  another  area  .  For  example,  the  tech  reps’  opinions  of  MAES  will 
impact  whether  the  FTSC’s  endorse  MAES.  The  tech  reps’  opinions  could  also  influence 
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whether  or  not  the  sailors  use  MAES.  Without  the  backing  of  the  FTSC’s, 
COMNAVSURFLANT  and  COMNAVSURFPAC  are  unlikely  to  support  MAES.  If  the 
type  commanders  do  not  support  MAES  then  the  fleet  commanders  will  certainly  not 
support  MAES. 

Thus,  if  the  deployment  team  does  not  gain  tech  reps’  support,  the 
interdependencies  among  the  risks  including  tech  rep  resistance,  hierarchical  resistance, 
chain-of-command  support,  FTSC  endorsement,  and  system  use  by  fire  controlmen,  could 
cause  support  for  MAES  to  unravel.  Any  strategy  to  handle  these  risks  should  leverage 
the  interdependencies  to  optimize  risk  mitigation  outcomes  while  economizing  project 
resources.  In  the  above  example,  the  tech  reps  represent  the  greatest  leverage  point. 

3.  Risk  Handling 

Risk  handling  is  the  final  activity  in  the  risk  management  process.  Risk  handling 
involves  techniques  such  as  avoidance,  control,  assumption,  and  transfer  to  mitigate  or 
eliminate  the  unwanted  results  of  risks.  (DSMC,  1989) 

As  a  brief  review  of  these  terms,  risk  avoidance  involves  selecting  a  lower  risk 
choice  from  several  alternatives.  Risk  control  includes  the  continual  monitoring  and 
adjustment  of  a  program,  while  risk  assumption  suggests  that  some  consequences  will  be 
accepted.  Finally,  risk  transfer  entails  reducing  risk  exposure  by  sharing  the  risk  with 
another  activity. 

Applying  these  four  handling  techniques  to  MAES  risks  would  show  that  all  of  the 
Class  II  and  Class  III  risks  fall  under  the  risk  control  handling  technique.  By  definition, 
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Class  II  and  Class  in  risks  require  close  management  attention  and  monitoring  which  are 
essential  elements  of  the  risk  control  handling  technique.  Controlling  risk  includes  “the  use 
of  reviews,  risk  reduction  milestones,  development  of  fallback  positions,”  and  other 
management  actions  which  should  be  part  of  an  overall  risk  reduction  plan.  (DSMC, 
1989) 

The  underlying  assumption  about  risk  control  is  that  an  awareness  exists  about 
certain  risks  and  there  is  a  flexible  plan  for  dealing  with  those  risks.  Preliminary 
quantification  provides  the  initial  “awareness”  of  the  risks  while  extracting  the  common 
elements  generates  the  starting  point  for  a  risk  reduction  plan. 

With  respect  to  risk  control,  Class  IE  risks  share  two  common  leverage  points: 
communication  and  perception.  Essential  to  mitigating  Class  HI  .  risks,  open 
communications  serve  to  build  alliances  and  uncover  negative  undercurrents  before  they 
become  threats.  Perceptions  influence  such  risks  as  tech  rep  and  FC  resistance,  chain-of- 
command  support,  FTSC  endorsement,  and  attitude  towards  change.  An  effective 
marketing  campaign  can  cultivate  beneficial  perceptions  about  MAES  and  breakdown  the 
silent  barriers  created  by  perceptions  which  might  threaten  the  project.  Experts 
throughout  the  software  development  industry  agree  that  marketing  is  a  crucial  part  of  any 
implementation  plan.  (Dart,  1996;  Fowler,  1996)  In  this  case,  it  can  also  be  an  important 
part  of  the  MAES  risk  reduction  plan. 

Risk  assumption  can  be  appropriate  in  some  situations.  For  MAES,  some  risk 
assumption  occurs  in  the  areas  of  knowledge  accuracy,  software 
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reliability/quality/availability,  supportability,  hardware  durability,  and  data  gathering.  Risk 
control  and  risk  assumption  techniques  are  actually  combined  to  handle  knowledge 
accuracy  and  software  reliability/quality/availability  risks.  This  happens  because  despite 

our  best  efforts  at  controlling  these  risks,  some  risk  will  persist  that  we  must  eventually 
accept. 

Computer  literacy  risk  and  perhaps  hardware  durability  risk  could  be  handled  with 
risk  avoidance  techniques.  Computer  literacy  risk  could  be  avoided  by  providing  more 
extensive  computer  training.  Hardware  durability  risk  might  be  avoided  by  procuring 
ruggedized  rather  than  COTS  laptop  computers. 

4.  The  Risk  Management  Plan 

The  activities  described  above  form  the  foundation  for  the  risk  management  plan 
which  will  be  integrated  into  the  overall  MAES  implementation  plan.  Identification  of 
those  factors  important  to  implementation  success  is  the  next  step  in  developing  an 
implementation  plan. 

Because  of  the  many  definitions  of  risk,  one  could  argue  that  risks  and  factors 
important  to  implementation  success  are  closely  related.  For  this  analysis,  factors  differ 
from  risks  in  that  factors  are  more  system  specific  and  risks  are  more  project  specific. 

D.  FACTORS  IMPORTANT  TO  IMPLEMENTATION  SUCCESS 

Some  information  systems  professionals  suggest  that  Expert  Systems  (ES)  are 
dead.  At  least  three  factors  including  maintainability,  justifying  the  use  of  dedicated 
platforms,  and  implementation  are  cited  as  problem  areas.  (Davenport,  1995)  Experience 
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has  shown  that  implementing  new  technology  is  usually  more  difficult  than  we  expect. 
(Davenport,  1995)  Given  the  importance  of  implementation,  this  section  will  explore  the 
various  factors  which  determine  an  implementation  plan’s  success  or  failure. 

1.  Framework  for  the  Implementation  Strategy 

If  a  generic  implementation  strategy  existed  for  deploying  technological 
innovations,  such  as  expert  systems,  it  would  likely  need  to  be  tailored  to  the  particular 
characteristics  of  the  specific  system  (Meyer  and  Curley,  1991).  Meyer  and  Curley  (1991) 
have  built  a  two  dimensional  framework  for  evaluating  the  characteristics  of  various 
expert  systems.  They  classify  expert  systems  based  on  knowledge  complexity  and 
technological  complexity. 

Measures  of  complexity  are  determined  by  incorporating  a  number  of  factors  into 
each  dimension.  Knowledge  complexity  includes  such  factors  as  the  number  of  separate 
areas  of  expertise  needed  to  deal  with  a  problem,  the  amount  of  training  and  experience 
required  of  an  expert,  and  the  nature  of  the  system’s  output.  Technological  complexity 
considers  such  factors  as  the  number  of  rules  or  the  size  of  the  knowledge  base,  the 
diversity  of  information  sources,  and  the  degree  of  diffusion  of  users  of  the  system. 
(Meyer  &  Curley,  1991) 

Based  on  the  measure  of  complexity  for  the  two  dimensions,  Meyer  and  Curley 
(1991)  classify  expert  systems  (ES)  into  one  of  four  quadrants.  Figure  2-2  graphically 
depicts  the  classification.  The  four  quadrants  are  described  below: 

I.  Low  knowledge/low  technology.  Since  these  ES  contain  the  lowest  levels  of 
both  technology  and  knowledge,  they  can  often  be  developed  by  end  users  and  deployed 
on  stand-alone  PC’s.  They  generally  represent  a  few  hundred  rules  at  most. 
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n.  High  knowledge/low  technology.  Based  on  “deep”  knowledge,  these  ES 
capture  detailed  knowledge  from  domain  experts  that  can  cover  several  complex  domains. 
Nonetheless,  they  can  be  deployed  on  stand-alone  PC’s  which  might  support  small 
databases. 

III.  Low  knowledge/high  technology.  These  ES  are  based  on  simple  knowledge 
requirements.  The  complexity  in  these  systems  comes  from  the  considerable  system 
integration  challenges  which  can  involve  hundreds  of  different  locations. 

IV.  High  knowledge/high  technology.  Based  on  knowledge  that  is  both  “broad” 
and  “deep”  these  ES  often  require  complex  efforts  in  areas  like  database  management  and 
systems  integration. 
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Figure  2-2.  Information  Systems  Complexity  Matrix 
(From  Meyer  and  Curley,  1991) 


Efforts  aimed  at  categorizing  a  number  (50  in  this  example)  of  different 
knowledge-based  systems  indicate  that  these  systems  fall  into  all  four  categories.  (Meyer 
and  Curley,  1991)  Given  this  tendency,  a  single  implementation  plan  would  not  be 
appropriate  for  all  systems.  (Bradley  and  Hauser,  1995) 
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2.  Implementation  Factors 

An  important  element  in  implementation  planning  appears  to  be  correctly 
categorizing  the  ES  as  early  as  possible  so  that  implementation  efforts  can  be  customized 
to  fit  the  system.  A  precursor  to  categorization  would  be  identifying  key  factors  and 
activities  within  the  four  categories  which  are  important  to  ES  implementation  success. 
Factors  expected  to  influence  user  acceptance  of  a  technological  innovation,  such  as  an 
ES,  can  be  classified  based  on  innovation  characteristics,  organizational  influences,  and 
individual  differences.  (Bradley  and  Hauser,  1995) 

Innovation  characteristics  concern  the  users’  perceptions  of  the  innovation.  A 
person  who  has  a  strong  negative  attitude  about  computer  technology  could  be  expected 
to  have  a  negative  attitudes  towards  an  expert  system.  (Bradley  and  Hauser,  1995) 
Similarly,  if  something  in  the  implementation  process  creates  unrealistic  expectations  in  the 
users,  they  can  become  resistant  to  change  and  jeopardize  the  implementation.  (Bradley 
and  Hauser,  1995) 

Organizational  influences  include  such  factors  as  user  participation  in  development 
and  implementation,  rewards  for  using  the  system,  training,  and  informal  and  formal 
organizational  support.  From  these  factors,  user  involvement  in  the  development  process 
and  availability  of  training  have  been  shown  to  be  very  positive  influences  on 
implementation  success.  (Bradley  and  Hauser,  1995)  However,  not  everyone  agrees  that 
user  participation  in  development  or  implementation  plays  a  significant  role  in 
implementation  success  (Ginzberg,  1981;  Markus  and  Keil,  1994). 
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While  the  support  of  top  management  is  important  to  implementation  success, 
supervisor’s  desires  and  peer  influences  can  also  be  controlling  factors  in  the 
implementation  process.  (Leonard-Barton,  1987)  Supervisors’  attitudes  towards  a  new 
ES  can  either  accelerate  or  hinder  the  diffusion  of  the  innovation  among  users.  (Bradley 
and  Hauser,  1995)  In  situations  where  peers  are  actively  involved,  they  can  help  speed 
acceptance  of  the  ES  if  they  hold  positive  beliefs  about  the  ES.  (Leonard-Barton,  1987) 

With  regard  to  individual  differences  and  their  impact  on  implementation  success, 
factors  from  job  tenure  to  cosmopolitanism  have  been  shown  to  have  an  effect  on  the 
implementation  process.  The  degree  to  which  individual  differences  influence  users  of  ES 
depends  on  the  perceived  change  created  by  the  ES.  User  resistance  might  be  expected  to 
be  high  based  on  a  particular  set  of  individual  characteristics,  but  user  perceptions  of  the 
change  could  completely  invalidate  expectations.  (Bradley  and  Hauser,  1995). 

Bradley  and  Hauser  (1995)  state  that  “the  manner  in  which  the  implementation  is 
managed  impacts  both  the  users’  perceptions  of  the  system  and  the  speed  of  its  diffusion 
among  the  user  group.”  Borrowing  from  Meyer  and  Curley  (1991)  and  incorporating  the 
factors  described  above,  Bradley  and  Hauser  (1995)  offer  a  framework  for  determining 
which  factors  should  be  emphasized  for  each  of  the  four  classes  of  ES.  Table  III  provides 
an  overview  of  this  framework. 

The  success  of  any  implementation  plan  aimed  at  introducing  new  technology 
depends  heavily  on  an  effective  marketing  or  sales  campaign  (Leonard-Barton,  1987;  Dart, 
1996,  Fowler,  1996).  A  practical  way  to  approach  a  new  implementation  challenge  is  to 
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identify  those  factors  which  will  most  influence  user  acceptance  of  the  innovation  and  then 
focus  on  those  factors.  In  resource  constrained  organizations  this  approach  can  help 
narrow  the  scope  of  the  project  to  an  economically  feasible  level.  (Bradley  and  Hauser, 
1995) 
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Table  HI.  Relative  Importance  of  ES  Implementation  Factors 
(From  Bradley  and  Hauser,  1995) 

Importance  values  of  high,  medium,  and  low  were  determined  for  the  factors 
within  each  category  of  ES  by  analyzing  the  characteristics  of  each  ES  and  by  applying 
information  from  existing  implementation  literature  (Bradley  and  Hauser,  1995).  The  key 
to  this  framework  is  not  in  the  methods  that  were  used  to  develop  it  but  in  the  analytical 
tools  it  provides  for  developing  an  implementation  plan. 
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As  an  example  of  how  this  process  might  work,  consider  developing  an 
implementation  plan  for  a  category  II  expert  system.  At  a  minimum,  the  plan  should  focus 
on  those  factors  which  are  rated  as  being  highly  influential.  Based  on  Table  El,  those 
factors  include  the  user  s  perceptions  of  computing  technology,  user  involvement  in  the 
ES  design  and  implementation,  supervisor  support,  and  the  user’s  perception  of  change. 

Referring  to  Figure  2-2,  MAES  would  be  considered  a  category  II  expert  system 
because  it  captures  detailed  or  “deep”  knowledge  from  a  domain  expert  but  can  be 
deployed  on  a  standalone  computer.  Categoiy  n  expert  systems  are  described  as 
knowledge  intensive  systems.  (Meyer  and  Curley,  1991)  The  implementation  factors  for 
a  category  E  expert  system,  shown  in  Table  El,  should  be  considered  when  developing  the 
MAES  implementation  plan. 

The  implementation  factors  offered  throughout  the  implementation  literature  as 
being  critical  to  successful  implementation  generally  parallel  those  factors  described  above 
(Ginzberg,  1981;  Tyran  and  George,  1993;  Markus  and  Keil,  1994).  A  few  of  these 
factors  are  described  below. 

Based  on  a  study  of  45  different  ES  projects,  Tyran  and  George  (1993)  found  that 
the  five  implementation  factors  with  the  most  perceived  importance  were  assessment  of 
user  needs,  commitment  of  the  human  expert,  ease  of  ES  use,  commitment  of  the  user, 
and  top  management  support.  These  five  factors  closely  resemble  the  implementation 
factors  outlined  by  Bradley  and  Hauser  (1995). 
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Historically,  management  support  and  user  involvement  have  been  identified  as 
common  success  factors  in  MIS  implementation  projects.  (Ginzberg,  1981)  In  an  attempt 
to  further  refine  generic  implementation  issues,  Ginzberg  (1981)  found  through  statistical 
analysis  three  factors  which  were  most  significant  in  determining  implementation  success. 

The  first  factor  is  commitment  to  the  project,  which  involves  doing  everything 
necessary  to  ensure  that  the  problem  is  understood  and  that  the  system  developed  solves 
the  problem.  The  next  factor  is  commitment  to  change,  which  entails  the  willingness  of 
those  involved  to  make  the  changes  that  are  necessary  for  the  system  to  work.  The  last 
critical  factor  is  the  extent  of  project  definition  and  planning,  which  concerns  the  detailed 
analysis  of  issues  such  as  organizational  needs,  project  impacts,  training  requirements,  and 
role  identification.  (Ginzberg,  1981) 

Though  generic  in  nature  these  implementation  issues  provide  another  set  of 
factors  which  should  be  analyzed  together  with  previously  discussed  factors  to  isolate 
those  issues  deserving  the  most  attention  during  the  implementation  process.  This 
approach  acts  as  an  early  warning  system  helping  to  track  impending  failures  (Ginzberg, 
1981).  We  want  to  be  able  to  focus  implementation  efforts  to  save  resources,  but 
knowing  the  issues  helps  us  shift  the  likelihood  of  success  in  our  favor  by  giving  us 
guidelines  for  detecting  problems  which  might  lead  to  failure. 

Another  factor  that  can  influence  implementation  success  is  business  system 
design.  Tragically,  systems  that  work  well  technically  can  go  unused  if  they  are  not 
designed  for  implementability.”  Making  an  information  system  good  enough,  does  not 
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ensure  that  people  will  use  it.  System  users  must  be  motivated  to  do  what  the  system 
enables  them  to  do  and  the  system  can  not  make  it  harder  for  them  to  do  what  they  were 
motivated  to  do.  (Markus  and  Keil,  1994) 

When  systems  are  not  used  the  temptation  is  to  mandate  use.  Unfortunately, 
mandated  use  can  lead  people  to  use  a  system  in  ways  that  do  not  improve  their 
performance.  Generally,  when  a  system’s  design  conflicts  with  the  users’  motivations  and 
incentives,  managers  will  not  force  them  to  use  the  system.  (Markus  and  Keil,  1994)  For 
the  purposes  of  MAES’s  implementation,  the  development  process  is  too  far  along  to 
consider  building  implementability  into  the  business  system  design;  however,  some  of  the 
issues  related  to  business  system  design,  such  as  motivation  and  incentives,  will  be 
discussed  later  in  the  context  of  performance  measures  and  rewards. 

Considering  all  of  the  factors  described  above,  the  goal  for  building  an  ES  is 
organizational  improvement  (Markus  and  Keil,  1994).  With  MAES  organizational 
improvement  occurs  if  No-Fault  Evident  (NFE)  repair  parts  are  decreased  or  if  the  mean 
time  to  repair  (MTTR)  casualties  is  decreased.  To  achieve  organizational  improvement  or 
implementation  success,  the  system  must  be  used. 

Three  subgoals  comprise  the  overall  goal  of  organizational  improvement.  First, 
when  people  use  the  system  as  they  are  intended  to,  they  will  achieve  the  goal.  Second, 
the  system  must  have  the  functionality  and  user  interface,  so  that  users  can  easily  use  it  to 
accomplish  a  goal.  And,  third,  people  must  actually  use  the  system  in  the  intended  manner 
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which  means  management  has  to  measure,  monitor,  and  reward  their  progress  toward  the 
goal.  (Markus  and  Keil,  1994) 

E.  INTEGRATING  IMPLEMENTATION  FACTORS  AND  RISKS 

One  method  for  simplifying  the  complex  task  of  integrating  implementation  factors 
and  risks  into  a  successful  implementation  plan  is  to  begin  with  a  detailed  scenario  of  what 
the  ideal  implementation  plan  would  look  like.  From  there,  identify  the  current  state  and 
then  target  the  deficient  areas.  (Fowler,  1996)  Using  the  framework  provided  by  Bradley 
and  Hauser  (1995)  shown  as  Table  III,  we  begin  constructing  the  ideal  implementation 
scenario  by  stating  the  desired  outcomes  from  emphasizing  the  factors  important  to  the 
implementation  success  of  a  type  II  expert  system. 

In  addressing  implementation  factors,  the  ideal  implementation  plan  would: 

•  Reinforce  positive  attitudes  about  computer  technology  and  reverse  negative 
attitudes  about  computer  technology. 

•  Create  realistic  expectations  about  the  capabilities  of  MAES. 

•  Involve  the  users  in  the  implementation  plan  to  the  degree  that  they  feel  they 
have  influence  in  the  process. 

•  Promote  system  usage  through  appropriate  organizational  rewards. 

•  Provide  a  system  of  training  that  instills  confidence  in  the  users  and  offers  the 
opportunity  for  additional  instruction  on  request. 

•  Build  enthusiastic  support  at  all  levels  of  management,  from  the  Commanding 
Officer  to  work  center  personnel. 

•  Establish  several  consulting  aids  in  the  form  of  a  help  desk  or  points  of  contact 
of  MAES  advocates. 

•  Condition  MAES  users  so  that  they  will  be  amenable  to  the  changes  that 
MAES  will  bring  to  their  work  environment. 

In  addressing  implementation  risks,  the  ideal  implementation  plan  would  mitigate 
risks  by: 
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•  Creating  feedback  channels  flowing  from  the  ships,  the  fleet  training  centers, 
and  the  fleet  technical  support  centers,  so  that  as  errors  are  discovered  in  the 
knowledge  base,  corrections  can  be  made. 

•  Obligating  the  maker  of  the  expert  system  shell  to  a  3-5  year  support  contract 
and  obligating  appropriate  funds  for  NSWC  personnel  to  maintain  and  support 
MAES. 

•  Providing  hardware  from  reputable  companies  and  supporting  the  hardware 
with  appropriate  equipage  such  as  carrying  cases  and  surge  protectors. 

•  Including  basic  computer  training  in  the  initial  MAES  familiarization  training 

•  Winning  FTSC  technical  representatives’  support. 

•  Dissolving  resistance  to  change  among  fire  controlmen. 

•  Identifying  and  properly  handling  politically  sensitive  issues. 

•  Developing  ardent  chain-of-command  support  at  all  levels. 

•  Promoting  continued  excellent  relations  with  the  Fleet  Training  Centers. 

•  Building  a  quality  training  plan  that  reaches  all  of  the  targeted  audiences  and 
then  perpetuates  itself  so  that  MAES  use  is  not  jeopardized  by  the  transient 
assignment  of  Navy  personnel. 

The  ideal  implementation  plan  should  handle  the  implementation  factors  and  risks 
as  described  above.  Factor  consideration  and  risk  mitigation,  comprise  two  significant 
pillars  of  this  plan.  Common  threads  running  through  the  risks  and  factors  include  training 
in  various  forms,  overcoming  resistance  to  change,  building  positive  perceptions  and 
developing  pervasive  support  of  MAES.  Having  created  the  ideal  implementation  plan, 
the  next  step  is  to  assess  the  current  state  and  then  focus  on  the  selected  areas. 

F.  SUMMARY 

‘An  important  key  to  the  acceptance  and  use  of  expert  systems  in  organizations 
lies  in  effective  implementation.”  (Bradley  and  Hauser,  1995)  Effective  implementation 
hinges  on  how  well  the  implementation  plan  addresses  the  key  implementation  factors  and 
anticipates  the  “show  stopping”  risks.  Effective  implementation  also  depends  on  how  well 
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the  plan  is  executed.  A  great  plan  that  is  too  expensive  or  too  difficult  to  carry  out  has 
minimal  value. 

Based  on  the  analysis  provided  in  this  chapter,  the  MAES  implementation  team 
should  begin  by  focusing  their  efforts  on  the  “high  emphasis”  factors  for  a  Category  H 
expert  system  as  shown  in  Table  II.  The  important  factors  include  emphasis  on  the  user’s 
perceptions  of  computing  technology,  user  involvement  in  the  ES  design  and 
implementation,  supervisor  support,  and  user’s  perception  of  change. 

The  team  should  also  begin  by  addressing  the  Class  II  and  Class  m  risks  These 
risks  pose  the  most  serious  threats  to  MAES’s  success.  The  Class  HI  risks  are  hierarchical 
resistance,  tech  rep  resistance,  FTSC  endorsement,  training,  chain-of-command  support, 
and  deployment  funding.  Because  of  the  overlap  between  risks  and  factors,  this  process 
should  be  a  concurrent  effort  rather  than  separate  endeavors. 

A  comprehensive  implementation  plan  built  on  the  factors  and  risks  described 
above  is  not  provided.  Instead,  the  next  three  chapters  will  offer  individual 
implementation  plans  dealing  with  the  deployment  of  MAES  to  the  ships,  the  integration 
of  MAES  into  the  formal  training  pipeline,  and  the  transition  of  MAES  to  NSWC  PHD  for 
life  cycle  support.  Each  of  these  three  plans  will  use  the  ideal  implementation  scenario  as 
their  benchmark.  From  there,  the  “current  state”  will  be  assessed  which  will  help  the 
deployment  team  target  the  deficient  areas. 
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HI.  DEPLOYING  MAES  TO  ALL  MK  92  MOD  2  FCS  SHIPS 

A.  OVERVIEW 

This  chapter  discusses  the  long-term  implementation  plan  for  deploying  MAES  to 
all  MK  92  Mod  2  FCS  ships.  The  core  issues  covered  by  this  chapter  include  the 
hardware,  documentation,  training,  and  support  requirements  necessary  to  successfully 
deploy  MAES. 

Before  discussing  the  core  implementation  issues,  two  subsidiary  issues  are 
addressed.  The  first  subsidiary  issue  concerns  “lessons  learned”  from  the  initial 
deployment  of  the  MAES  prototype.  Additionally,  “lessons  learned”  from  initial  efforts  to 
schedule  the  full-scale  deployment  of  the  updated  MAES  prototype  are  discussed.  The 
second  subsidiary  issue  concerns  the  MAES  software  approval  process.  These  two 
subsidiary  issues  provide  a  background  for  consideration  of  the  core  issues  mentioned 
above. 

B.  LESSONS  LEARNED  FROM  INITIAL  DEPLOYMENT 

This  section  discusses  the  “lessons  learned”  both  from  the  initial  deployment  of  the 
MAES  prototype  and  from  the  type  commander  scheduling  process  that  might  help  shape 
the  long-term  implementation  of  MAES.  Due  to  funding  constraints,  the  MAES 
prototype  was  not  implemented  as  planned.  Thus,  empirical  information  about  full-scale 
prototype  implementation  is  limited.  Regardless,  there  are  still  “lessons  learned”  to 
convey  that  might  be  useful  in  the  eventual  deployment  of  MAES. 
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From  the  deployment  of  an  early  prototype  version  of  the  MAES  calibration 
module  aboard  a  COMNAVSURFPAC  ship  lessons  were  learned  about  how  sailors  may 
or  may  not  use  MAES  and  the  laptop  computer  on  which  MAES  is  loaded.  Sailors  loaded 
their  preventive  maintenance  system  (PMS)  schedules,  their  training  plans,  and  their 
evaluations  onto  the  MAES  laptop.  Based  on  this  experience,  one  should  expect  that  the 
uses  for  the  laptop  will  expand  to  the  laptop’s  capacity  unless  measures  are  taken  to 
restrict  use. 

Other  lessons  learned  from  the  prototype  were  that  more  experienced  FC’s  were 
reluctant  to  use  MAES  because  they  did  not  feel  that  they  needed  it  and  familiarity  with 
MAES  centered  around  one  or  two  FC’s.  One  must  keep  in  mind,  however,  that  this  was 
an  early  prototype  of  the  first  module.  The  experienced  fire  control  technicians  had 
excellent  knowledge  of  the  troubleshooting  procedures  in  this  domain.  Also,  many  of  the 
enhancement  features  (such  as  pictures  and  “how”  procedures)  designed  to  encourage  the 
use  of  MAES,  were  not  implemented  in  the  prototype.  Both  of  these  lessons  learned  fall 
into  risk  categories  discussed  in  Chapter  II. 

Even  though  full-scale  prototype  deployment  has  not  occurred,  prospective 
implementation  dates  and  requests  for  three  to  six  Atlantic  Fleet  ships  were  submitted  to 
the  Atlantic  Fleet  scheduling  conference.  Several  things  were  learned  from  this  process. 
First,  the  scheduling  process  must  be  initiated  one  quarter  prior  to  the  planned 
implementation  quarter  so  that  inputs  are  available  for  the  applicable  scheduling 
conference. 


44 


Second,  even  though  inputs  are  submitted  to  the  scheduling  conference  through 
NSWC,  who  sends  a  representative  to  the  conference,  other  involved  activities,  such  as 
the  Naval  Science  Advisor’s  Program,  must  also  be  notified  of  the  deployment  team’s 
intentions.  The  final  lesson  learned  from  the  scheduling  process  is  that  ships  are  hard  to 
catch  inport.  Finding  three  ships  inport  at  the  same  time  is  unlikely.  This  point  will  have 
a  significant  bearing  on  how  full-scale  implementation  efforts  are  conducted. 

C.  MAES  SOFTWARE  APPROVAL  PROCESS 

The  software  approval  process  involves  at  least  four  steps.  The  first  step  involves 
obtaining  ISEA  approval.  The  second  step  involves  obtaining  NAVSEA  approval.  The 
third  step  entails  establishing  a  Memorandum  of  Understanding  (MOU)  between 
NAVSEA  and  the  fleet  commanders  and  the  fourth  step  involves  obtaining  the  approval  of 
the  type  commanders  to  deploy  MAES  aboard  their  ships.  Details  of  these  four  steps 
should  be  explored  and  negotiated  after  completion  of  the  production  version  of  MAES. 

As  McGaha  noted,  standard  Navy  procedures  for  deploying  diagnostic  software  to 
the  fleet  have  not  been  established.  (McGaha,  1994)  Until  a  policy  is  established, 
developers  must  seek  implementation  authority  from  the  type  commanders.  For  MAES, 
the  NAVSEA  project  manager  for  the  MK  92  FCS  must  obtain  written  authority  from  the 
type  commanders  (step  four)  to  deploy  MAES  to  the  ships.  This  written  authority  will  be 
in  the  form  of  a  message  from  the  type  commanders  to  all  ships  with  MK  92  Mod  2  FCS. 
(McGaha,  1994)  Recent  conversations  with  type  commanders’  staff  members  indicate 
that  these  requirements  are  still  intact.  (Whitman,  1996;  Simino,  1996) 
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While  this  approval  process  might  be  administratively  burdensome  it  accomplishes 
several  objectives.  It  establishes  implied  command  support  for  MAES.  It  advertises 
MAES  up  and  down  the  chain-of-command,  and  it  provides  authoritative  guidance  for 
ship’s  Commanding  Officers  concerning  the  use  of  MAES. 

NAVSEA’s  request  to  the  type  commanders  should  contain  a  recommended  draft 
of  the  approval  message  that  includes  MAES  points  of  contact  and  various  reporting 
procedures.  The  deployment  team  should  work  closely  with  NAVSEA  and  the  type 
commanders’  staffs  concerning  the  content  of  the  approval  message.  If  carefully  drafted, 
the  type  commanders’  approval  message  could  give  MAES  a  huge  boost  during  the  early 
days  of  implementation. 

D.  HARDWARE  IMPLEMENTATION  ISSUES 

Many  of  the  issues  in  this  section  were  previously  examined  by  McGaha  (1994). 
Rather  than  restating  previous  findings,  this  section  will  draw  on  McGaha’ s  research  to 
make  recommendations  pertinent  to  the  long-term  implementation  of  MAES. 

1.  Dedicated  Laptop  Versus  Ship’s  Existing  Resources 

Ship’s  existing  computer  resources  can  be  placed  into  three  categories  -  desktop 
computers,  portable  computers,  and  personally  owned  computers.  The  inventory  of  these 
resources  varies  among  ships  and  ship  classes,  but  as  one  might  expect,  the  FFG’s  have 
the  fewest  computer  resources.  While  installing  MAES  on  existing  shipboard  computers 
might  be  the  cheapest  way  to  deploy  MAES,  this  option  introduces  undesirable  variables 
into  the  implementation  plan. 
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Experience  using  MAES  on  various  laptops  and  desktop  computers  indicates  that 
different  hardware  and  software  configurations  can  complicate  the  initial  loading  and  use 
of  MAES.  In  one  case,  a  desktop  computer  loaded  with  MAES  would  not  properly 
display  the  program  because  of  incorrect  video  drivers.  In  another  case,  one  laptop  and  a 
desktop  loaded  with  MAES,  both  running  Windows®  95,  would  not  properly  display 
several  MAES  screens.  These  complications  may  not  be  easy  to  overcome  for  people 
who  are  unfamiliar  with  computers.  Furthermore,  variation  across  the  wide  spectrum  of 
computers  that  might  be  found  on  ships  would  create  a  maintenance  nightmare  for  the 
MAES  configuration  manager. 

Deploying  MAES  on  a  dedicated  laptop  computer  accomplishes  the  following: 

•  Minimizes  the  range  of  potential  hardware  and  software  compatibility  problems 
which  in  the  long-term  should  make  the  systems  easier  to  maintain. 

•  Creates  the  best  assurance  that  computer  resources  will  be  available  for  fire 
control  technicians  when  they  need  it. 

•  Acts  as  a  marketing  tool  for  MAES.  This  new  “toy”  will  invite 
experimentation  and  use. 

Most  FFG’s  have  no  more  than  two  laptop  computers  on  board.  (Simino,  1996). 
Given  their  scarcity,  it  is  unlikely  an  existing  laptop  computer  would  be  transferred  to  the 
FC’s  for  their  exclusive  use.  Using  an  existing  desktop  computer  might  be  an  option  but 
that  would  limit  MAES’s  functionality  as  pictures  and  “Hows”  would  not  be  readily 
available  to  technicians.  (McGaha,  1994)  Additionally,  as  with  the  laptops,  there  are  no 
guarantees  that  a  desktop,  convenient  to  the  FC’s,  would  be  available.  This  area  is  to  be 
evaluated  in  more  detail  during  the  COMN A V SURFL ANT  evaluation. 
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An  added  benefit  of  providing  the  ships  with  a  laptop  computer  is  that  a  new 
computer  comes  with  a  warranty.  This  is  especially  important  since  there  are  no  Navy 
operated  computer  repair  facilities  available  to  Atlantic  Fleet  ships.  The  east  coast  Shore 
Intermediate  Maintenance  Activities  (SIMA)  no  longer  provide  computer  repair  support 
to  the  ships.  (Simino,  1996)  With  the  protection  of  a  warranty,  dedicated  laptop 
computers  provide  the  best  hardware  solution  for  successfully  deploying  MAES. 

There  is  no  standard  laptop  computer  designated  for  shipboard  use;  however,  any 
laptop  procurement  strategy  should  include  consideration  of  future  shipboard  support 
issues.  (Orchard,  1996;  Curtis,  1996)  One  approach  to  ensure  future  supportability  is  to 
purchase  computers  from  contracts  that  are  accessible  by  the  ships.  Purchasing  the  laptop 
computers  from  an  existing  GSA  contract  or  one  of  the  Navy’s  Indefinite  Delivery 
Indefinite  Quantity  (IDIQ)  contracts  offers  the  most  practical  approach.  Since  the  ships 
have  access  to  these  contracts,  this  approach  ensures  consistency  between  what  the  ships 
can  purchase  and  what  is  purchased  for  the  ships. 

2.  Commercial-Off-The-Shelf  (COTS)  Versus  Ruggedized  Computers 
This  comparison  weighs  lower  prices  for  COTS  computers  against  greater 
reliability  for  ruggedized  computers.  As  mentioned  in  Chapter  II,  unreliable  hardware  can 
pose  a  risk  to  successful  implementation.  Of  course,  increased  reliability  comes  at  a  price. 
Based  on  information  provided  by  the  U.  S.  Army,  ruggedized  computers  do  not  always 
provide  greater  reliability.  (Army,  1996) 
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At  today  s  prices,  ruggedized  computers  are  roughly  three  to  four  times  as 
expensive  as  COTS  laptop  computers.  Fielding  MAES  on  ruggedized  computers  would 
require  significantly  higher  upfront  expenditures  and  would  also  burden  ships  with  higher 
replacement  costs  than  for  COTS  laptops.  Presently,  there  is  no  funding  available  to 
purchase  ruggedized  computers  for  evaluation. 

One  alternative  to  leverage  the  lower  prices  and  perhaps  comparable  reliability  of 
COTS  laptops  would  be  to  initially  purchase  extra  COTS  laptops.  These  extra  laptops 
could  be  used  to  quickly  replace  failed  computers.  This  strategy  might  save  money 
upfront  as  computer  buys  could  be  made  incrementally  based  on  failure  rates.  In  addition 
to  saving  money,  this  strategy  could  improve  the  chances  for  implementation  success  by 
simplifying  users’  maintenance  responsibilities. 

3.  Government  Procurement 

In  addition  to  the  procurement  options  proposed  by  McGaha  (1994),  the  option  of 
purchasing  the  laptop  computers  using  a  General  Services  Administration  (GSA)  contract 
should  be  considered.  The  combination  of  the  National  Performance  Review  and  the 
Federal  Acquisition  Streamlining  Act  of  1994,  perpetuated  by  the  effective  repeal  of  the 
Brooks  Act,  gave  GSA  the  incentive  to  change  many  of  its  old  restrictive  policies.  GSA 
prices  and  services  are  now  more  competitive  with  Indefinite  Delivery  Indefinite  Quantity 
(IDIQ)  contracts.  (GCN,  1996) 

For  purchases  over  $2,500,  GSA  customers  select  the  “best  value”  from  three 
competitors.  GSA  customers  have  the  flexibility  to  negotiate  prices  with  the  vendors  to 
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get  the  lowest  available  price.  Maximum  order  limitations  that  might  have  prevented 
purchasing  MAES  laptops  through  GSA  have  been  eliminated.  Further,  the  requirement 
to  synopsize  orders  over  $50,000  has  been  abolished  by  GSA.  (GCN,  1996)  GSA 
reforms  have  made  this  procurement  alternative  worth  investigating  for  the  MAES 
laptops’  purchase. 

4.  Accountability  and  Security 

Implementing  the  MAES  laptop  as  a  piece  of  MK  92  FCS  test  equipment  offers 
the  best  assurances  that  the  computer  will  be  used  for  its  intended  purpose,  that  there  will 
be  a  reduced  susceptibility  to  viruses,  and  that  it  will  be  inventoried  frequently.  (McGaha, 
1994)  Another  option  would  be  to  classify  the  MAES  laptop  as  controlled  equipage. 
While  this  option  would  impose  regular  inventory  guidelines  and  place  the  laptop  in  the 
signed  custody  of  MK  92  FCS  work  center  personnel  it  would  also  open  up  the  computer 
for  uses  other  than  MAES. 

Controlled  equipage  designations  do  not  imply  the  same  type  of  use  restrictions 
that  test  equipment  designations  do.  Based  on  the  time  and  expense  required  to  develop 
MAES,  restricted  use  of  the  laptop  by  designating  it  as  test  equipment  is  justified.  An 
NSWC  representative  is  currently  evaluating  the  requirements  to  include  the  MAES  laptop 
as  a  piece  of  test  equipment  on  an  allowance  equipage  list  (AEL).  (Edozie,  1996) 

5.  Fielding,  Maintenance,  and  Replacement 

McGaha  (1994)  suggested  three  alternatives  for  fielding  computers  to  the  ships. 
The  alternatives  were  that  NAVSEA,  the  type  commanders,  or  the  ships  would  purchase 
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or  provide  the  laptop  computers.  (McGaha,  1994)  Due  to  funding  limitations,  two  of 
those  options  should  be  eliminated.  Neither  the  type  commanders  nor  the  ships  have  the 
budgeted  funding  to  procure  dedicated  laptops  for  the  initial  deployment  of  MAES. 
(Curtis,  1996)  If  MAES  will  be  deployed  on  laptop  computers,  then  NAVSEA  should 
fund  the  purchase  of  the  computers  for  initial  system  deployment. 

Maintenance  responsibilities  for  the  computers  should  rest  with  the  ships.  They 
would  be  supported  by  computer  warranties.  As  mentioned  above,  computer  maintenance 
support  from  Navy  activities  is  no  longer  available  on  the  east  coast  (Simino,  1996) 
Computer  maintenance  support  is  available  on  the  west  coast  at  the  Shore  Intermediate 
Maintenance  Activity  (SIMA),  San  Diego,  but  their  experience  shows  that  replacing 
defective  laptops  is  normally  more  economical  than  repairing  them.  (Tan,  1 996) 

Providing  reliable  hardware  will  be  an  important  element  in  the  successful 
implementation  of  MAES.  The  reliability  of  COTS  laptop  computers  aboard  ships  is 
unknown.  Based  on  personal  experience,  personal  computers  are  much  more  durable  in 
the  harsh  shipboard  environment  than  one  would  expect  but  the  hardware  still  represents  a 
risk.  Durable,  hard  shelled  carrying  cases  and  surge  protectors  would  further  reduce  the 
risk. 

This  risk  can  be  further  mitigated  by  providing  responsive  support  to  MAES  users 
who  encounter  problems  with  their  computers.  One  alternative  is  that  the  system 
configuration  manager  at  NSWC  could  be  responsible  for  replacing  defective  computers 
during  the  first  year  of  MAES’s  deployment.  Damaged  computers  would  be  the 
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responsibility  of  the  ships  to  repair  or  replace.  Computers  infected  by  viruses  would  also 
be  the  responsibility  of  the  ships  to  repair  or  replace. 

E.  DOCUMENTATION  REQUIREMENTS 

The  MAES  implementation  package  should  include  a  MAES  user’s  manual  (see 
Cepek,  1996),  user’s  manuals  for  all  prebundled  software  such  as  Microsoft  DOS®  and 
Microsoft  Windows®,  and  user’s  manuals  for  the  hardware.  In  addition  to  preloading  the 
MAES  software,  two  copies  of  the  MAES  software  diskettes  should  be  provided.  One 
copy  should  remain  in  the  work  center  and  the  other  copy  should  be  turned  over  to  the 
ship’s  ADP  security  officer. 

Elements  of  the  MAES  maintenance  manual  described  by  McGaha  including  the 
knowledge  diagnostic  trees;  procedure  diagrams;  and  testing,  validation  and  verification 
forms  are  not  necessary  to  support  MAES  at  the  shipboard  level.  (McGaha,  1994) 
Transfer  of  these  items  to  the  software  life  cycle  manager  will  be  discussed  in  Chapter  V. 

F.  TRAINING  REQUIREMENTS 

The  nucleus  of  MAES  training  contains  three  major  elements:  the  trainers,  the 
methods  and  media  used  to  deliver  training,  and  the  students.  This  section  discusses  each 
of  these  elements. 

1.  The  Trainers 

NSWC  PHD,  the  Fleet  Training  Centers  (FTC),  and  the  Fleet  Technical  Support 
Centers  (FTSC)  represent  the  spectrum  of  MAES  trainers.  After  the  full-scale 
deployment  of  MAES,  NSWC  will  probably  not  be  involved  in  further  training  efforts. 
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On-going  training  for  MAES  will  be  conducted  by  the  FTC’s  but  this  training  differs  from 
implementation  training.  With  NSWC  at  one  end  of  the  spectrum  and  the  FTCs  at  the 
other,  FTSC’s  involvement  falls  somewhere  between  these  two  ends.  FTSC  involvement 
could  provide  an  important  connecting  bond  between  the  initial  implementation  training 
provided  by  NSWC  and  the  on-going  classroom  training  provided  by  the  FTC’s. 

As  mentioned  in  Chapter  II,  deployment  training  is  susceptible  to  several  risks. 
Sailors  who  transfer  from  a  command  without  MAES  may  not  receive  adequate  training. 
At  the  same  time,  those  sailors  who  receive  the  training  may  transfer  causing  MAES 
knowledge  to  lapse.  Developers  of  shipboard  information  systems  have  found  that 
personnel  turnover  can  leave  a  ship  with  no  corporate  knowledge  of  a  system  and  no 
traceability  for  what  has  happened  with  the  system.  (Williams,  1996;  Pandit;  1996)  From 
personal  experience  aboard  one  of  the  first  ships  equipped  with  Shipboard  Non-tactical 
Automated  Program  II  (SNAP  II),  this  risk  seems  largely  ignored  by  some  implementation 
teams. 

FTSC  representatives  participation  in  on-going  shipboard  MAES  training  could 
mitigate  this  risk  by  perpetuating  implementation  training.  FTSC  representatives  are  in  a 
perfect  position  to  become  the  guardians  of  shipboard  MAES  corporate  knowledge.  Their 
expertise  combined  with  their  frequent  visits  to  most  of  the  MK  92  Mod  2  FCS  ships  place 
them  in  a  position  to  monitor  MAES  usage  and  training  with  minimal  effort. 
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2.  Methods  and  Media  Used  to  Deliver  Training 

Several  methods  and  media  are  available  to  disseminate  MAES  training.  The 
various  methods  and  media  are  listed  below  from  the  most  preferred  to  the  least  preferred: 

•  On-site  training  by  a  deployment  team  from  NSWC. 

•  On-site  training  by  FTSC  representatives. 

•  Training  by  a  deployment  team  at  a  central  site  such  as  the  FTC’s. 

•  Training  at  a  central  site  using  video-teleconferencing  capabilities. 

•  Videotaped  training  with  videotapes  mailed  to  the  ships. 

•  Written  training  mailed  to  the  ships  with  the  program. 

The  optimal  training  plan  would  include  on-site  training  at  each  of  the  ships.  This 
training  could  be  conducted  by  NSWC  or  FTSC  representatives.  If  performed  by  NSWC 
representatives,  this  could  be  the  most  expensive  and  time  consuming  training  method.  As 
pierside  residents,  the  FTSC  representatives  could  save  money  in  terms  of  travel  expenses 
if  they  implement  the  software  and  perform  the  training  during  “windows  of  opportunity” 
created  by  routine  technical  assist  visits. 

Another  approach  would  be  to  train  several  ships  at  once  at  a  central  site  such  as  a 
fleet  training  center.  This  method  has  advantages  in  that  it  saves  time  and  travel  money 
and  may  offer  the  fewest  distractions  for  the  students.  A  variation  of  this  training  method 
would  be  to  conduct  the  training  at  a  central  site  in  each  homeport  using  video¬ 
teleconferencing  capabilities.  One  of  the  disadvantages  to  this  method  might  be  the  one- 
hour  time  restriction  normally  imposed  on  video  teleconferences. 

Under  strict  funding  and  time  constraints,  videotaped  training  should  be 
considered.  While  not  the  optimal  method,  videotaped  training  offers  the  deployment 
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team  the  opportunity  to  carefully  structure  the  presentation’s  content  and  delivery.  As  a 
last  resort,  a  written  MAES  training  guide  based  on  the  user’s  manual  could  be  included  in 
the  MAES  implementation  package. 

The  training  plan  for  full-scale  MAES  implementation  should  be  tailored  based  on 
the  findings  from  the  prototype  deployment.  It  may  be  discovered  that  a  combination  of 
the  above  methods  offers  the  best  chance  for  successful  implementation  training.  For 
specific  information  about  the  prototype  deployment  training  plan  refer  to  Cepek  (1996). 

3.  The  Students 

The  population  of  potential  MAES  students  includes  everyone  from  Commanding 
Officers  to  software  maintenance  engineers.  Of  course,  the  most  important  students  are 
the  shipboard  FC’s.  The  deployment  team  must  be  prepared  to  train  all  the  potential 
MAES  students. 

The  trainers  will  be  the  first  students.  This  means  that  new  members  of  the 
deployment  team  must  train  themselves  with  regards  to  MAES  before  they  can  train 
others.  For  tips  about  the  most  effective  training  techniques  for  introducing  MAES,  the 
trainers  should  contact  the  FTC  instructors  who  have  experience  with  MAES.  They 
should  also  refer  to  the  lessons  learned  from  the  prototype  deployment  training. 

G.  SUPPORT  REQUIREMENTS  AND  PROCEDURES 

This  section  describes  the  support  requirements  and  procedures  that  should  be 
addressed  during  MAES  implementation  training.  Areas  of  concern  include  hardware 
support,  software  support  and  various  reporting  procedures. 


55 


1.  Hardware  Support 

To  minimize  hardware  risks,  the  MAES  configuration  manager  at  NSWC  PHD 
should  fully  checkout  all  deployable  laptops  prior  to  issue.  Even  though  they  will  be 
covered  by  warranties,  defective  laptops  pose  a  risk  to  successful  implementation  because 
unreliable  hardware  can  prejudice  users  against  MAES.  A  complementary  alternative  to 
minimize  hardware  risk  would  be  for  NSWC  PHD  to  replace  problem  hardware  and 
assume  responsibility  for  pursuing  warranty  work  during  the  initial  implementation  phase. 
As  a  part  of  this  plan,  replacement  computers  could  be  staged  at  the  FTSC’s  or  at  the 
ships’  squadron  offices. 

2.  Software  Support 

Software  support  issues  fall  into  two  categories,  prebundled  software  and  MAES 
software.  Within  this  context,  software  support  can  be  further  divided  into  immediate 
“help”  related  support  and  non-urgent  support.  Prebundled  software  includes  software 
such  as  Microsoft  Windows®  that  may  be  pre-loaded  on  the  laptop  computer.  Support 
for  prebundled  software  should  be  pursued  by  the  ships  through  the  applicable  software 
company.  The  MAES  configuration  manager  should  stay  current  on  prebundled  software 
issues  and  provide  timely  guidance  to  the  users. 

Support  for  MAES  software  should  be  provided  by  the  MAES  configuration 
manager  and  the  MAES  software  engineer.  This  support  should  be  available  by  telephone, 
Naval  message,  or  SALTS  message.  Current  addresses  and  points  of  contact  should  be 
either  in  the  user’s  manual  or  in  an  addendum  to  the  user’s  manual. 
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3.  Reporting  and  Updating  Procedures 

Beyond  “help”  related  questions,  issues  arise  related  to  reporting  errors,  submitting 
trouble  reports,  and  recommending  changes  that  are  serious  but  not  urgent.  Existing 
reports  such  as  the  NSWC  PHD  Software  Trouble  Report,  the  Digital  Systems  Feedback 
Report  (NSWSES-3 142/1),  and  the  Engineering  Change  Proposal  (DD  1692)  provide  a 
solid  foundation  for  addressing  these  issues. 

The  Software  Trouble  Report  (STR)  provides  a  communications  channel  for 
reporting  problems  in  the  software  or  for  proposing  enhancements  to  the  software.  It  is 
used  mainly  by  engineers,  such  as  the  In-Service  Engineering  Agent  (ISEA),  Software 
Support  Agent,  Design  Agent,  System  Integration  Agent,  Technical  Direction  Agent,  and 
the  Independent  Verification  and  Validation  (IV&V)  agent,  who  are  familiar  with  the 
software  and  the  MK  92  Mod  2  FCS.  The  STR  is  the  medium  by  which 
problems/enhancements  are  entered  into  the  Configuration  Control  System  (PC-CCS). 
PC-CCS  is  a  database  used  to  document  and  track  configuration  related  data.  (Gorham, 
1996) 

Designed  for  use  by  sailors  and  support  personnel,  the  Digital  Systems  Feedback 
Report  (DSFR)  serves  the  same  function  as  the  STR,  but  uses  a  simpler  format.  When  a 
DSFR  is  received  by  the  ISEA  (NSWC  PHD  for  MAES),  the  problem  is  validated  through 
a  preliminary  investigation,  and  if  valid,  the  DSFR  is  rewritten  as  an  STR  for  submission 
to  PC-CCS.  (Gorham,  1996) 


57 


Periodically,  open  STRs  are  segregated  into  functionally  related  groups  and 
Engineering  Change  Proposals  (ECPs)  are  written.  ECPs  describe  each  problem  in  the 
group,  the  design  of  the  proposed  solution,  the  interactions  between  the  fixes,  and  the 
impacts  on  other  hardware,  software,  or  documentation.  (Gorham,  1996b)  The  software 
update  process  might  proceed  as  follows  (Gorham,  1996b): 

•  DSFRs  are  submitted  by  users,  validated,  and  rewritten  as  STRs  by  the 
ISEA/SSA.  Designers,  ISEA/SSA,  users,  and  other  involved  agencies  also 
submit  STRs. 

•  The  Configuration  Manager  (CM)  enters  the  STRs  into  the  PC-CCS  database. 

•  STRs  are  periodically  reviewed  by  the  Software  Configuration  Management 
Board  (SCCB)  and  assigned  a  priority,  category,  and  status.  Priorities  range 
from  high  to  low.  Categories  are  assigned  codes  of  S  (software 
implementation  error,  no  impact  on  requirements  documentation),  E  (design 
error,  affects  code  and  requirements  specifications),  or  D  (affects  requirements 
documents  only)  depending  on  the  type  of  error  and  its  affect  on  requirements 
documentation.  Status  can  be  indicated  by  a  variety  of  codes  meaning  open, 
under  investigation,  closed,  etc. 

•  After  approval  by  the  SCCB,  certain  ECPs  are  selected  for  a  software  build 
referred  to  as  a  version  release.  A  test/project  plan  is  written  and  an  estimate  is 
provided. 

•  When  funded,  the  designs  in  the  ECPs  are  coded  and  tested.  Using  PC-CCS, 
the  CM  documents  and  tracks  implementation  of  these  corrections. 

•  When  fully  and  successfully  tested,  the  software  version  is  delivered  to  the 
Fleet. 

The  DSFR  provides  fire  controlmen  with  a  simple  form  that  they  can  use  for  a 
variety  of  purposes.  Whether  reporting  software  errors,  submitting  trouble  reports,  or 
recommending  enhancements,  sailors  can  use  the  DSFR  as  their  link  to  the  software 
configuration  managers.  The  User’s  Manual  includes  a  copy  of  a  DSFR.  The 
communications  channels  required  to  support  the  DSFR  reporting  process  will  be 
discussed  in  Chapter  V. 
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H.  SUMMARY  -  THE  IMPLEMENTATION  PLAN 

The  hardware,  documentation,  training,  and  support  issues  discussed  in  this 
chapter  will  be  influenced  by  the  experiences  gained  from  the  full-scale  deployment  of  the 
MAES  prototype.  While  the  various  alliances  and  agreements  needed  to  ensure  successful 
long-term  implementation  can  not  be  solidified  yet,  the  deployment  team  should  begin  to 
identify  and  pursue  the  relationships,  activities,  and  policies  important  to  a  successful 
implementation. 

The  MAES  long-term  implementation  plan  is  included  as  Appendix  B.  The 
framework  for  this  plan  was  adapted  from  the  Fleet  Material  Support  Office’s  (FMSO) 
Implementation  Planning  Guide.  (Moran,  1996;  FMSO,  1994)  The  reader  should 
understand  that  this  implementation  plan  is  subject  to  change  based  on  “lessons  learned” 
from  the  MAES  prototype  deployment.  This  implementation  plan  should  be  viewed  as  a 
working  document  rather  than  as  a  definitive  implementation  guide. 
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IV.  INTEGRATION  OF  MAES  INTO  THE  MK  92  MOD  2  FCS 
“C”  SCHOOL  CURRICULUM 


A.  OVERVIEW 

MAES  was  introduced  to  the  first  group  of  MK  92  Mod  2  FCS  students  in 
January  1996.  Through  the  cooperation  and  support  of  FTC  San  Diego,  laboratory 
experiments  were  conducted  with  these  students  which  provided  the  first  empirical 
evidence  that  MAES  performs  as  promised.  These  test  results  are  summarized  in 
Appendix  A. 

The  Fleet  Combat  Training  Center  (FCTC),  Dam  Neck,  the  east  coast  equivalent 
of  FTC  San  Diego,  received  MAES  software  and  a  familiarization  presentation  in  June 
1996.  At  this  writing,  FCTC  instructors  are  just  beginning  to  learn  how  to  use  MAES 
and  to  appreciate  the  power  of  this  program. 

While  MAES  has  not  been  formally  integrated  into  the  MK  92  Mod  2  FCS 
curriculum,  FTC  San  Diego’s  experiences  with  the  program  over  the  past  two  years 
provides  valuable  insight  into  the  integration  process.  The  guidance  received  from  FTC 
San  Diego  will  serve  as  the  basis  for  the  MAES  integration  plan. 

B.  DOCUMENTATION  REQUIREMENTS 

Though  the  training  centers  will  not  perform  life  cycle  maintenance  functions  on 
the  MAES  software,  system  knowledge  diagrams  that  were  developed  by  the  domain 
expert  should  be  provided  to  them.  This  will  allow  the  training  centers  to  analyze  the 
knowledge  diagrams  if  the  need  or  desire  arises.  Additional  documentation,  such  as  a 
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user’s  manual,  complete  with  information  about  obtaining  and  loading  upgrades, 
submitting  a  change  proposal  or  error  report,  and  receiving  help,  should  also  be  provided 
to  the  training  centers.  Sometimes  forgotten,  the  training  centers  should  receive  all 
follow-on  documentation  that  is  distributed  to  the  ships  so  that  they  can  keep  their  MAES 
training  current  with  fleet  developments. 

Manufacturers’  user’s  manuals  for  the  hardware,  including  warranty  information, 
and  users’  manuals  for  the  supporting  software,  such  as  Microsoft  Windows®  and 
Microsoft  DOS®  6.2,  should  be  provided  to  the  training  centers.  Documentation 
pertaining  to  the  expert  system  shell  should  not  be  required  by  the  schools  as  they  will  not 
have  the  development  system. 

C.  HARDWARE/SOFTWARE  REQUIREMENTS 

Both  of  the  training  centers  have  been  provided  with  at  least  one  laptop  computer 
for  dedicated  MAES  use.  Concurrent  with  the  deployment  of  MAES  to  the  ships,  each 
training  center  should  receive  a  software  and  hardware  package  identical  to  the  versions 
sent  to  the  ships.  Ideally,  each  training  center  should  receive  three  laptop  computers. 
Two  of  the  laptops  would  be  used  in  the  laboratory  and  the  other  one  would  be  connected 
to  a  personal  computer  compatible  overhead  projector  for  use  in  the  classroom. 
Procedures  should  be  in  place  to  ensure  that  the  training  centers  are  on  the  distribution  list 
for  future  software  updates. 
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D.  IMPACT  ON  THE  CURRICULUM 

Introducing  new  material  into  a  course  usually  involves  modifications  to  various 
training  materials  ranging  from  the  formal  training  plan  to  instructor  guides.  Even  a  simple 
change  to  a  curriculum  can  result  in  hours  of  administrative  work  to  ensure  that  all 
affected  parts  of  the  curriculum  have  been  changed. 

MAES  s  integration  into  the  MK  92  Mod  2  FCS  curriculum  will  not  require 
extensive  changes  to  the  course  documentation  since  the  curriculum  is  currently  under 
review.  (Heidenreich,  1995)  Any  changes  initiated  by  the  introduction  of  MAES  can  be 
written  into  the  new  course  rather  than  treated  as  a  modification  to  the  old  course. 

Experience  has  shown  that  classroom  training  does  not  need  to  change  to 
accommodate  MAES.  By  learning  about  MAES  after  the  Daily  Systems  Operability  Test 
(DSOT)  module,  students  do  not  need  additional  classroom  training  to  understand  MAES. 
A  simple  demonstration  in  the  lab  on  how  to  use  MAES  for  fault  isolation  is  all  that 
students  need  to  get  started.  Hands-on  experience  is  the  best  way  to  learn  how  to  use 
MAES.  (Myers,  1996) 

Based  on  FTC  San  Diego’s  work,  the  only  changes  to  the  course  may  be  in  a 
couple  of  the  lab  assignments.  Modifications  to  the  allotted  course  hours  will  not  be 
required  to  support  MAES  training. 

E.  COURSE  MATERIALS  REQUIREMENTS 

Existing  course  materials  that  provide  fault  isolation  scenarios  for  laboratory 
troubleshooting  practice  will  support  the  inclusion  of  MAES  into  the  laboratory 
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assignments.  Given  a  laptop  computer  loaded  with  MAES,  the  training  centers  should  not 
require  any  additional  course  materials. 

F.  SUMMARY  -  INTEGRATION  PLAN 

The  integration  of  MAES  into  the  MK  92  Mod  2  FCS  curriculum  will  not  require 
the  same  extensive  implementation  effort  necessary  for  fielding  MAES  to  the  ships.  By 
the  time  the  production  version  of  MAES  reaches  the  ships  FCTC  Dam  Neck  will  have 
worked  with  MAES  for  almost  a  year  and  FTC  San  Diego  will  have  over  two  years 
experience  with  MAES.  This  simplifies  the  integration  process  and  allows  the  deployment 
team  to  narrowly  target  long-term  support  related  issues  rather  than  familiarization  issues. 

A  plan  for  integrating  MAES  into  the  MK  92  Mod  2  FCS  curriculum  is  provided 
as  Appendix  C. 
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V.  TRANSITIONING  LIFE  CYCLE  SUPPORT  FOR  MAES  TO 

NSWC  PHD 


A.  OVERVIEW 

This  chapter  discusses  the  activities  and  supporting  documentation  required  to 
transition  life  cycle  support  for  MAES  to  NSWC  PHD.  This  process,  while  completing 
the  Naval  Postgraduate  School’s  involvement  in  MAES,  establishes  the  foundation  for  the 
future  of  MAES.  The  quality  of  the  documentation  passed  to  NSWC  will  be  a  key 
determinant  in  the  maintainability  of  MAES.  This  will  impact  the  long-term  success  of  the 
system. 

As  was  done  with  the  shipboard  MAES  implementation  plan  and  the  fleet  training 
centers’  MAES  integration  plan,  risk  mitigation  will  be  considered  in  the  MAES  transfer 
plan.  Maintainability  and  documentation  are  just  two  of  the  risks  that  the  MAES 
deployment  team  must  consider  when  transferring  this  system.  Other  risks  include  attitude 
towards  change,  supportability,  and  training. 

This  section  begins  with  a  discussion  of  the  documentation  needed  for  NSWC 
PHD  to  maintain  MAES.  Next,  training  requirements  are  described.  An  analysis  of  the 
communications  channels  required  to  maintain  MAES  follows.  The  chapter  concludes 
with  a  description  of  annual  support  costs. 

B.  DOCUMENTATION  REQUIREMENTS 

The  documentation  package  for  MAES  will  be  based  on  the  guidelines  provided  by 
military  standard  498  (MIL- STD-49 8),  Software  Development  and  Documentation. 
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These  guidelines  will  be  tailored  as  necessary  to  accommodate  the  visual  programming 
environment  which  was  used  to  develop  MAES.  Elements  of  the  documentation  package 
will  include  a  system  level  description,  a  software  design  document,  the  MAES  user’s 
manual,  and  a  version  description  document.  (Lester,  1996) 

The  system  level  description  will  provide  an  overview  of  the  system’s  purpose,  the 
system  development  environment,  the  target  operational  environment,  and  the  system 
architecture.  Providing  greater  detail  than  the  system  level  description,  the  software 
design  document  will  focus  on  the  system  architecture,  the  methods  used  to  generate 
problem  analysis  trees,  and  descriptions  of  the  problem  analysis  diagnostic  trees. 

The  MAES  user’s  manual  will  offer  users  information  on  how  to  install,  initialize, 
and  operate  MAES.  Procedures  for  getting  help,  reporting  problems,  or  recommending 
changes  will  also  be  provided  as  an  addendum  to  the  user’s  manual. 

The  version  description  document  will  list  the  version  of  tools  used  to  develop 
MAES,  version  numbers  of  MAES  modules,  versions  of  commercial  software  which  are 
compatible  with  this  release  of  MAES,  any  known  problems  with  this  release  of  MAES, 
operator  work-arounds  for  any  known  problems,  and  points  of  contact  for  MAES. 

The  system  level  description  of  MAES  is  included  as  Appendix  D  and  the  user’s 
manual  is  provided  by  Cepek’s  Master’s  Thesis.  (Cepek,  1996)  The  software  design 
document  and  the  version  description  document  are  being  developed  for  the  calibration 
and  performance  modules  of  MAES  by  the  respective  contractors  and  the  NSWC  project 
engineer. 
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C.  TRAINING  REQUIREMENTS 

Training  requirements  must  be  considered  for  both  the  MAES  configuration 
manager  and  the  MAES  software  engineers.  As  an  active  participant  in  the  development 
of  MAES,  the  configuration  manager  at  NSWC  PHD  has  experience  with  the 
development  tool  (Adept),  prototype  versions  of  MAES,  and  the  knowledge 
documentation.  Additional  training  for  the  configuration  manager  should  not  be  required. 

Written  using  a  visual  programming  language,  MAES  will  likely  pose  a  new 
challenge  to  software  engineers  at  NSWC  who  have  minimal  experience  with  such  a  tool. 
Transferring  MAES  to  the  NSWC  software  engineers  will  bring  change  to  their  work 
environment  because  MAES  was  developed  with  SoftSell  Adept.  A  visual  programming 
language.  Adept  is  somewhat  different  from  the  languages  normally  used  by  NSWC 
software  engineers.  (Smith,  1994)  Their  attitudes  towards  this  change  pose  significant 
potential  risks  to  the  successful  transfer  of  MAES.  Formal  Adept  training,  discussed 
below,  may  offer  the  best  opportunity  to  positively  influence  their  attitudes. 

Even  for  seasoned  software  engineers,  training  represents  a  serious  risk  when 
introducing  a  new  tool.  To  mitigate  the  training  risk  and  to  ensure  the  successful  transfer 
of  MAES,  NSWC  software  engineers  should,  like  other  MAES  users,  receive  training  but 
of  a  more  specialized  nature. 

Formal  Adept  training  should  be  provided  to  at  least  one  of  the  software  engineers 
who  will  maintain  MAES.  (Gorham,  1996a)  This  will  minimize  the  learning  curve  for  this 
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tool  and  hopefully  decrease  the  time  it  takes  to  perform  maintenance  on  MAES.  It  will 
also  provide  key  points  of  contact  with  SoftSell  should  questions  arise. 

D.  MAINTAINING  MAES 

MAES  maintenance  is  a  broad  based  function  involving  the  efforts  of  personnel 
from  NSWC,  the  FTSC’s,  the  training  centers,  and  the  ships.  Communication  is  the  key 
to  a  successful  maintenance  program.  Communication  channels  must  be  established  to 
facilitate  feedback  from  the  ships,  to  encourage  critical  review  and  input  from  the  ships, 
the  FTSC  s  and  the  training  centers,  and  to  coordinate  the  ongoing  improvement  of 
MAES  through  updates  by  NSWC. 

As  discussed  in  Chapter  II,  many  of  the  serious  risks  threatening  the  success  of 
MAES  can  be  mitigated  by  developing  effective  communications.  The  long-term  success 
of  the  MAES  maintenance  program  will  depend  on  active  and  open  communications 
among  all  involved  activities.  The  communication  channels  needed  to  support  MAES 
include  feedback  channels,  configuration  management  channels,  and  update  channels. 

1.  Feedback  Channels 

Before  the  transfer  of  MAES  to  NSWC,  responsive  feedback  channels  must  be  in 
place  to  support  maintenance  efforts  and  to  assist  MAES  users.  These  communication 
channels  must  support  activities  such  as  error  reporting,  recommending  changes,  placing 
trouble  calls,  and  requesting  help. 

Rather  than  creating  new  MAES  specific  procedures  and  reports,  existing 
feedback  mechanisms  should  be  adapted  as  necessary  to  support  MAES.  This  minimizes 
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the  number  of  different  reporting  channels  which  essentially  accomplish  similar  tasks. 
Standard  reporting  procedures  for  different  systems  simplifies  the  process  for  the  sailors. 
(Curtis,  1996) 

Existing  reports  such  as  the  NSWC  PHD  Software  Trouble  Report  (SFR),  the 
Digital  Systems  Feedback  Report  (DSFR)  (NSWSES-3 142/1),  and  the  Engineering 
Change  Proposal  (ECP),  DD  Form  1692,  provide  mechanisms  for  reporting  trouble, 
getting  help,  and  recommending  changes.  Discussed  in  Chapter  m,  these  forms  are 
included  as  Appendix  E.  The  MAES  User’s  Manual  includes  a  copy  of  a  DSFR.  ECPs 
and  STRs  are  forms  routinely  used  by  MK  92  FCS  engineers  and  should  not  require 
additional  distribution  to  support  MAES  feedback. 

While  these  feedback  channels  can  be  used  by  the  ships,  the  FTSC’s,  or  the 
training  centers,  they  are  primarily  designed  to  support  the  ships.  Other  channels  are 
required  to  support  long-term  configuration  management  issues  which  are  best  handled  by 
the  technical  experts. 

2.  Configuration  Management  Channels 

The  objective  of  configuration  management  channels  should  be  to  link  the 
technical  experts  together  in  a  cooperative  effort.  This  can  be  accomplished  informally  by 
promoting  e-mail  correspondence  between  the  technical  experts  and  formally  by  including 
MAES  as  a  new  program  covered  by  the  existing  MK  92  Software  Configuration  Control 
Board  (SCCB).  (Gorham,  1996b) 
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Membership  on  the  board  might  initially  include  NPS  as  the  Design  Agent,  NSWC 
PHD  4C45  as  ISEA  and  Software  Support  Agent,  NSWC  PHD  4C46  as  System 
Integration  Agent,  and  NAVSEA  91W3PT,  the  MK  92  Software  Program  Manager,  as 
the  Chair.  (Gorham,  1996b)  Proposed  membership  on  the  board  does  not  include 
representatives  from  the  FTSC’s,  the  training  centers,  or  the  type  commanders  who  are 
valuable  sources  of  feedback  concerning  MAES.  Their  inputs  would  be  channeled  to  the 
board  through  reports  such  as  STRs  or  through  other  correspondence  with  the  ISEA. 

The  board’s  main  objective  would  be  to  provide  long-range  direction  and  planning 
for  MAES  software.  In  negotiating  the  details  of  the  Software  Transition  Plan,  the 
composition  of  the  SCCB  should  be  considered  as  well  as  the  possibility  of  establishing  a 
separate  configuration  control  board  to  support  MAES.  The  MK  92  Software  Program 
Manager  should  determine  the  configuration  control  board’s  composition  based  on 
recommendations  from  the  MAES  configuration  manager  at  NSWC  PHD. 

3.  Update  Channels 

As  updates  are  formalized  based  on  inputs  received  through  the  feedback  and 
configuration  management  channels,  the  task  of  making  and  distributing  the  updates 
arises.  The  SCCB  will  ultimately  have  responsibility  for  deciding  the  extent  of  the  changes 
to  MAES  and  how  frequently  updates  will  be  sent.  Everything  will  be  contingent  on 
adequate  funding.  Generally,  updates  should  be  provided  once  a  year  unless  a  major 
change  to  the  system  occurs  that  warrants  more  frequent  updates.  (Gorham,  1996)  Once 
the  changes  have  been  made,  the  next  task  is  distributing  the  updates. 
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Mail  has  been  the  traditional  method  used  to  send  updates  to  the  ships.  (Gorham, 
1996)  The  Streamlined  Automated  Logistics  Transmission  System  (SALTS) 
offers  a  cheaper,  faster,  more  efficient  way  to  distribute  updates  to  the  ships.  Through 
telephone  lines  inport  and  satellite  links  underway,  all  ships  have  SALTS  capabilities. 

SALTS  provides  users  with  a  range  of  services  from  transmitting  messages  or 
passing  e-mail  to  sending  or  receiving  digital  files.  By  posting  MAES  updates  to  the 
SALTS  bulletin  board,  NSWC  could  save  time  and  money  while  making  the  latest  version 
of  MAES  immediately  available  for  ships  to  download  at  their  convenience. 

To  use  SALTS,  NSWC  PHD  would  need  to  purchase  the  SALTS  software,  which 
costs  about  $1000,  and  install  it  on  a  computer  with  a  modem  access.  NSWC  PHD  would 
receive  their  own  SALTS  address  which  could  be  used  to  communicate  with  the  ships  and 
about  2000  other  government  activities  throughout  the  world.  Since  NSWC  has  about  20 
existing  SALTS  locations,  NSWC  PHD  may  be  able  to  share  SALTS  with  an  existing 
NSWC  site.  (Friedrichs,  1996)  SALTS  could  prove  to  be  an  important  link  in  the  MAES 
communication  network  if  the  NSWC  MAES  configuration  manager  and  software 
engineer  elect  to  exploit  this  capability. 

E.  ANNUAL  SUPPORT  COSTS 

Annual  support  costs  cover  activities  such  as  system  configuration  management 
and  software  configuration  management.  Hidden  in  the  annual  support  costs  are  elements 
of  risk.  Risks  such  as  knowledge  accuracy,  maintainability,  documentation,  and 
supportability  will  all  impact  annual  support  costs. 
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Qualitatively,  the  consequences  from  the  occurrence  of  these  events  can  be  rated 
from  minor  to  moderate  threats  requiring  some  management  involvement.  Quantitatively, 
the  costs  from  the  occurrence  of  these  events  can  only  be  guessed.  How  much  more  will 
annual  support  costs  be  if  the  software  is  difficult  to  update  or  some  of  the  knowledge  is 

inaccurate?  A  range  of  annual  support  costs,  as  shown  in  Table  IV,  may  provide  the  best 
answer. 


Position 

Man-years 

Hours 

Hourly 

Rate 

Subtotal 

Total 

.25 

440 

$55 

Qtr  Yr  Option 

.25 

440 

$55 

$24,200 

$48,400 

gBnjnni 

.5 

880 

$55 

E55!ES5353!£3i 

.5 

880 

$55 

$48,400 

$96,800 

I 

1759 

$55 

$96,745 

ESSZsBSSllSH 

1 

1759 

$55 

$96,745 

Table  IV.  Range  of  Annual  Support  Costs 
The  hourly  rate  shown  in  Table  IV  is  based  on  NSWC’s  stabilization  rate  for  fiscal 
year  1996.  The  hours  allotted  per  man-year  were  based  on  a  1759  hour  federal  work  year. 
(Gassman,  1996)  The  stabilization  rate  includes:  salary,  station  overhead,  leave,  holidays, 
retirement,  and  other  fringe  benefits. 

Table  IV  illustrates  that  the  range  of  annual  support  costs  spans  from  about 
$48,400  to  almost  $193,500.  Cost  estimates  in  this  range  should  be  used  with  caution 


because  they  probably  understate  the  actual  salary  costs.  The  understatement  results  from 
vacation  time  and  other  compensatory  time-off  that  might  extend  the  timeframe  but  not 


the  number  of  hours  expended  to  maintain  MAES. 
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As  an  example,  assume  that  MAES  takes  one  quarter  man-year  to  maintain.  Also 
assume  that  the  system  configuration  manager  has  six  weeks  of  vacation  time.  If  his 
vacation  days  are  evenly  distributed  across  four  quarters  then  he  will  take  about  eight  days 
off  during  each  quarter.  This  means  that  his  actual  time  spent  on  maintenance  might  be 
440  hours  but  his  actual  time  expended  will  be  closer  to  500  hours  which  will  add  another 
$3,300  to  annual  support  costs. 

Other  costs  such  as  the  administrative  expenses  of  distributing  updated  software 
might  also  be  considered,  but  they  will  likely  add  little  to  the  total  expenses  in  comparison 
to  salary  expenses.  Depending  on  the  involvement  of  FTSCLANT  and  FTSCPAC 
representatives,  their  efforts  might  also  be  included  in  annual  support  cost  estimates  if 
significant  time  is  required  of  them. 

F.  SUMMARY  -  SOFTWARE  TRANSITION  PLAN 

As  defined  in  MIL-STD-498,  “the  Software  Transition  Plan  (STrP)  identifies  the 
hardware,  software,  and  other  resources  needed  for  life  cycle  support  of  deliverable 
software  and  describes  the  developer’s  plans  for  transitioning  deliverable  items  to  the 
support  agency.”  (MEL-STD-498,  1994)  The  deliverable  items  include  documents  such  as 
the  system  level  description,  the  software  design  document,  the  MAES  user’s  manual  and 
the  version  control  document. 

The  formal  STrP  includes  major  sections  from  all  of  these  documents.  It  can  also 
incorporate  information  about  annual  support  costs  and  recommendations  for  establishing 
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communication  channels,  discussed  above.  An  STrP  template  (Data  Item  Description), 
DD  Form  1664,  taken  from  MIL-STD-498  is  provided  in  Appendix  F. 

The  major  burden  of  providing  adequate  MAES  documentation  rests  with  the 
NSWC  project  manager,  NPS  staff,  and  the  civilian  software  engineers  who  developed 
the  calibration  and  performance  modules  of  MAES.  NSWC  shares  responsibility  with 
NPS  for  building  the  communications  infrastructure  that  will  ensure  the  successful  long¬ 
term  support  and  maintenance  of  MAES. 
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VL  SUMMARY  AND  CONCLUSIONS 


A.  OVERVIEW 

The  implementation  and  deployment  issues  related  to  fielding  MAES  are  divided 
into  three  separate  but  related  areas.  This  three-tiered  implementation  plan  includes 
MAES’s  deployment  to  the  fleet,  integration  into  the  formal  training  pipeline,  and 
transition  of  life  cycle  support  to  NSWC  PHD.  Within  this  framework,  the  research 
questions  are  examined  as  they  relate  to  hardware,  documentation,  training,  and  support 
requirements.  Important  implementation  factors  and  risks  are  incorporated  into  the 
answer  for  each  of  the  research  questions.  This  chapter  provides  a  summary  of  the 
implementation  factors,  risks,  and  other  issues  important  to  a  successful  fielding  of 
MAES. 

B.  SUMMARY 

This  thesis  answers  three  primary  research  questions  which  are  analyzed  according 
to  hardware,  documentation,  training,  and  support  requirements.  This  section  summarizes 
the  results  of  research  aimed  at  responding  to  these  questions.  Restated  from  Chapter  I, 
the  primary  research  questions  are  considered  below. 

1.  What  are  the  implementation  issues  for  deploying  the  MK  92  Mod  2 
FCS  MAES  to  all  MK  92  Mod  2  ships? 

The  implementation  issues  for  deploying  MAES  to  the  ships  include  topics  such  as 
approval  of  the  production  version  software,  selection  of  hardware,  accummulation  of 
appropriate  documentation,  development  of  a  training  plan,  and  establishment  of  support 
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procedures.  Associated  with  these  issues  are  risks  and  implementation  factors  specifically 
related  to  implementing  expert  systems  such  as  MAES. 

Implementation  factors  such  as  user’s  perception  of  computing  technology,  user 
involvement  in  expert  system  implementation,  supervisor  support,  and  user  perception  of 
change,  have  all  been  identified  as  being  highly  important  implementation  factors  for 
expert  systems  similar  to  MAES.  Along  with  these  implementation  factors,  project  risks 
such  as  computer  literacy,  various  levels  of  resistance,  chain-of-command  support,  and 
successful  deployment  training  should  be  incorporated  in  planning  for  MAES’s  full-scale 
deployment.  Appendix  B  provides  simple  guidelines  for  the  deployment  team  to  follow 
with  regards  to  these  implementation  factors  and  risks. 

One  tasking  for  the  MAES  deployment  team  will  be  to  get  the  production  version 
of  the  MAES  software  approved  for  distribution  to  the  fleet.  The  approval  process  will 
involve  coordination  between  NAVSEA,  the  ISEA,  the  fleet  commanders,  and  the  type 
commanders. 

Next,  the  deployment  team  must  consider  fielding  issues  related  to  hardware 
selection,  documentation,  training,  and  support.  Given  adequate  deployment  funding, 
MAES  should  be  deployed  on  COTS  laptop  computers  provided  to  the  ships  with  the 
hardware  and  prebundled  software  manufacturers’  user’s  manuals.  Appendix  G  provides 
a  summary  of  the  hardware,  software,  and  documentation  requirements  needed  to  field 
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The  ideal  implementation  training  scenario  would  have  the  deployment  team  from 
NSWC  PHD  providing  on-site  training  for  each  of  the  ships.  Alternatives  exist,  such  as 
video  teleconferencing,  if  on-site  training  is  too  expensive  or  impractical.  The  MAES 
support  plan,  which  establishes  procedures  for  obtaining  software  and  hardware  support, 
should  be  in  place  prior  to  fielding  the  system. 

2.  What  are  the  requirements  for  integrating  the  MK  92  Mod  2  FCS 
MAES  into  the  MK  92  Mod  2  “C”  School  curriculum  at  Fleet  Training  Center 
(FTC),  San  Diego  and  Fleet  Combat  Training  Center  (FCTC),  Dam  Neck? 

The  long  relationship  between  the  software  developers  at  NPS  and  the  fleet 
training  centers,  especially  FTC,  San  Diego,  simplifies  the  process  for  integrating  MK  92 
Mod  2  FCS  MAES  into  the  MK  92  Mod  2  “C”  School  curriculum.  Because  of  the 
training  centers’  prior  experience  with  MAES,  familiarization  training  should  not  be 
required.  Instead,  the  implementation  process  should  focus  on  post-implementation 
support  issues  which  are  important  to  the  long-term  viability  of  MAES. 

As  with  deploying  MAES  to  the  fleet,  implementation  factors  and  risks  should  be 
considered  when  integrating  MAES  into  the  “C”  school  curriculum.  Implementation 
factors  such  as  user’s  perception  of  computing  technology,  user  involvement  in  expert 
system  implementation,  supervisor  support,  and  user  perception  of  change,  have  all  been 
identified  as  being  highly  important  implementation  factors  for  expert  systems  similar  to 
MAES.  Along  with  these  implementation  factors,  project  risks  such  as  training  center 
acceptance  and  advocacy,  chain-of-command  support,  and  deployment  training  should  be 
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given  careful  consideration.  Appendix  C  provides  simple  guidelines  for  the  deployment 
team  to  follow  with  regards  to  these  implementation  factors  and  risks. 

The  integration  of  MAES  into  the  MK  92  Mod  2  FCS  curriculum  will  not  require 
the  same  extensive  effort  necessary  for  fielding  MAES  to  the  ships.  Major  changes  to  the 
curriculum  are  not  expected  as  a  result  of  including  MAES  training.  Hardware,  software, 
and  documentation  requirements  for  the  training  centers  will  parallel  the  fleet  requirements 
with  two  minor  exceptions.  If  funds  permit,  the  training  centers  should  be  provided  with  a 
laptop  and  a  compatible  overhead  projector  for  use  in  the  classroom.  Since  the  training 
environment  encourages  understanding  the  system,  the  training  centers  should  also  receive 
the  MAES  domain  expert’s  knowledge  documentation. 

Initial  implementation  success  at  the  training  centers  should  be  easy;  however,  the 
long-term  success  of  MAES  at  the  training  centers  will  hinge  on  the  life  cycle  manager’s 
dedication  to  keeping  the  training  centers  current  with  fleet  developments. 

3.  What  are  the  requirements  for  transitioning  life  cycle  support  for  the 
MK  92  Mod  2  FCS  MAES  software  to  NSWC  PHD? 

Maintainability,  documentation,  and  training  are  the  key  issues  related  to 
transitioning  life  cycle  support  for  MAES  software  to  NSWC  PHD.  The  quality  of  the 
documentation  passed  to  NSWC  will  be  important  to  the  long-term  maintainability  of 
MAES  software.  Adequate  training  will  also  be  important,  as  the  NSWC  software 
engineers  have  limited  experience  using  visual  programming  tools  such  as  SoftSell  Adept. 
Formal  training  from  SoftSell  will  likely  be  necessary. 
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The  documentation  required  to  support  MAES  should  include  a  system  level 
description,  a  software  design  document,  the  MAES  user’s  manual,  and  a  version 
description  document.  In  addition,  all  of  the  domain  expert’s  knowledge  documentation 
should  be  transferred  to  the  NSWC  software  engineers. 

Long-term  MAES  maintenance  will  require  establishment  of  communications 
channels  for  feedback,  configuration  management,  and  updates  distribution.  Existing 
reports  such  as  the  NSWC  PHD  Software  Trouble  Report  (STR),  the  Digital  Systems 
Feedback  Report  (DSFR),  and  the  Engineering  Change  Proposal  (ECP)  can  be  adapted  to 
accommodate  MAES  feedback  requirements.  The  DSFR  will  be  the  most  useful  feedback 
mechanism  for  the  ships. 

Based  on  the  information  received  through  the  feedback  channels,  a  configuration 
control  board  should  periodically  review  recommended  changes  to  MAES.  Composition 
of  a  configuration  control  board  for  MAES  should  be  discussed  between  the  ISEA  and 
NAVSEA.  Ultimately,  MAES  updates  should  be  distributed  to  the  ships  using  the  most 
economical  and  efficient  method  available.  The  Streamlined  Automated  Logistics 
Transmission  System  (SALTS)  may  satisfy  this  requirement. 

As  with  the  deployment  of  MAES  to  the  ships  and  the  training  centers, 
implementation  factors  and  risks  should  be  considered  in  transitioning  life  cycle  support 
for  MAES  to  NSWC  PHD.  The  risks  pertinent  to  MAES’s  transition  include 
maintainability,  documentation,  supportability,  training,  and  attitudes  towards  change. 


79 


B.  CONCLUSIONS 


Almost  five  years  after  the  idea  for  the  Maintenance  Advisor  Expert  System  was 
bom,  the  system  has  still  not  been  deployed  to  the  fleet.  The  fact  is,  MAES  may  never 
reach  the  fleet.  Despite  its  many  benefits,  such  as  improved  fault  isolation  capabilities, 
reduced  reliance  on  outside  technical  assistance,  and  decreased  replacement  of  perfectly 
good  repair  parts,  MAES  may  not  receive  deployment  funding  because  of  the  class  of 
ships  that  it  supports.  The  Oliver  Hazard  Perry  class  frigates  are  severely  challenged  by 
decreased  funding  levels  and  reduced  maintenance  support. 

After  deployment  funding,  resistance  from  competing  experts  poses  the  most 
significant  risk  to  MAES.  If  identified  and  addressed  early,  even  serious  risks,  like 
experts’  resistance,  can  be  controlled. 

Consideration  of  implementation  issues  and  factors  from  a  risk  management 
perspective  offers  the  best  opportunity  for  implementation  success  when  deploying 
technological  innovations  such  as  MAES.  The  risk  management  process  should  begin  the 
first  day  of  the  project  and  continue  throughout  the  innovation’s  useful  life. 

In  this  author’s  opinion,  obtaining  funding  and  support  for  technological 
innovations  in  today’s  budgetary  environment  requires  more  than  good  technology  and 
effective  marketing.  It  also  requires  picking  the  right  platform.  If  MAES  receives 
deployment  funding,  the  implementation  and  deployment  issues  discussed  in  this  thesis 
provide  a  good  foundation  for  a  successful  implementation  plan. 
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APPENDIX  A:  FTC  LAB  EXPERIMENTS  WITH  MAES 

A.  OVERVIEW 

This  appendix  shows  the  results  of  two  laboratory  experiments,  using  MAES, 
conducted  at  the  MK  92  Mod  2  FCS  “C”  school  in  San  Diego.  The  original  cost/benefit 
study  of  MAES  performed  in  1993  promised  reduced  mean-time-to-repair,  lower  no-fault 
evident  rates,  reduced  reliance  on  external  technical  assistance,  and  improved  shipboard 
training  and  knowledge  as  a  result  of  developing  and  deploying  MAES.  (Powell,  1993) 
Until  these  two  experiments  were  conducted  only  anecdotal  incidents  with  the  prototype 
system  provided  support  for  these  benefits. 

The  first  experiment  involved  separating  students  who  were  in  their  final  weeks  of 
training  into  two  groups.  One  group  would  use  traditional  troubleshooting  methods  and 
the  other  group  would  rely  on  MAES  for  troubleshooting  assistance.  Though  not 
scientific,  the  experiment  was  structured  to  reveal  the  power  of  MAES  as  a  fault  isolation 
tool. 

The  second  experiment  attempted  to  show  the  power  of  MAES  by  evaluating  the 
troubleshooting  performance  of  students  who  had  little  or  no  knowledge  of  the  MK  92 
Mod  2  FCS.  For  this  test,  new  students,  with  only  “A”  school  training,  were  taken  from 
the  Phalanx  Close-In  Weapons  Systems  class. 


81 


B.  THE  FIRST  EXPERIMENT 
1.  Experiment  Set-up 

The  class  was  first  separated  into  two  groups.  Each  group  was  further  divided 
into  teams  composed  of  two  or  three  members.  In  the  first  group,  students  used 
traditional  manual  troubleshooting  methods  to  isolate  the  test  faults.  In  the  second  group, 
students  used  MAES  to  isolate  test  faults.  In  each  set  of  tests,  both  groups  were  given  the 
same  fault  to  isolate  and  repair.  Three  faults  were  selected  that  fell  into  three  separate 
categories.  The  faults  and  the  fault  categories  are  described  below: 


Faults: 


Fault  #1:  All  CAS  NoGo’s;  open  pin  on  rigid  coax  W28  at  end 
connecting  output  BANDPASS  FILTER  FL3. 

Fault  #2:  CAS  Track  Target  NoGo’s;  Ground  TP15  of  UD412/A1 A4- 
A1 3  to  inhibit  CAS  Track  Target  Gate. 

Fault  #3:  All  CAS  NoGo’s  except  ECM;  Fault  UD412/A1A4-A1 
(Coho  Assy)  by  removing  +15VDC  at  A1-FL1. 


Fault  Categories: 


Category  1 
Category  2 
Category  3 


Problems  everyone  could  be  expected  to  solve. 
Problems  about  50%  of  the  class  could  solve. 
Problems  that  only  a  few  or  no  one  could  solve. 
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2.  Experiment  Results 

The  experiment  results  are  displayed  in  Tables  A-l,  A-2,  and  A-3  shown  below: 


Time  To  NFEs 

Category  Fault  Class  Rank  Repair  Selected 


1.  Traditional 

1 

3 

9  and  10 

30  minutes 

0 

1.  Traditional 

1 

3 

1  and  6 

28  minutes 

0 

1.  Traditional 

1 

3 

4  and  7 

10  minutes 

0 

1.  MAES  Team 

1 

3 

3,  5  and  8 

4  minutes 

0 

Table  A-l.  Fault  3/Category  1  Results 


As  illustrated  in  Table  A-l,  the  students  who  used  MAES  isolated  the  fault  faster 
than  any  of  the  traditional  troubleshooting  teams.  With  regards  to  the  MAES  team,  the 
instructor  commented  that  this  was  the  “easiest  lab  ever.”  MAES  picked  the  fault  strictly 
from  the  calibration  results  requiring  no  additional  troubleshooting  steps.  This  was  a 
category  one  problem  which  meant  that  everyone  in  the  class  was  expected  to  successfully 
isolate  this  fault. 


2.  Traditional 

2 

1 

3, 5  and  8 

62  minutes 

1 

2.  MAES  Team 

2 

1 

1  and  7 

62  minutes 

0 

2.  MAES  Team 

2 

1 

9  and  10 

40  minutes 

0 

Table  A-2.  Fault  1/Category  2  Results 


Table  A-2  shows  the  results  from  the  category  two  fault  isolation  efforts.  The 
most  significant  data  shown  in  this  table  is  that  the  traditional  team  pulled  a  No-Fault 
Evident  (NFE)  repair  part  which  was  valued  at  about  $4,000.  Neither  of  the  MAES  teams 
pulled  an  NFE  part  and  one  of  the  teams  finished  about  thirty  percent  faster  than  the  other 
two  teams. 


3a.  Traditional 

3 

2 

1  and  7 

65  minutes 

1 

3b.  Traditional 

3 

2 

3,  5  and  8 

100  minutes 

1 

3a.  MAES  Team 

3 

2 

4  and  6 

43  minutes 

0 

3b.  MAES  Team 

3 

2 

9  and  10 

55  minutes 

0 

Tab 

le  A-3. 

Fault  2/Category  3  Resul 

ts 
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Table  A-3  reveals  the  most  significant  results  from  this  MAES  performance 
evaluation.  As  shown  in  Table  A-3,  the  Non-MAES  team  3a  could  not  isolate  the  fault 
and  on  board  ship  would  have  requested  technical  assistance.  Both  MAES  teams  isolated 
this  fault  while  only  one  Non-MAES  team  solved  the  problem  taking  twice  as  much  time 
as  the  MAES  teams.  Additionally,  each  of  the  Non-MAES  teams  pulled  an  NFE  which 
cost  approximately  $7,000  each. 

During  this  performance  test  and  evaluation,  MAES  demonstrated  that  even  an 
early  prototype  version  has  the  power  to  improve  mean-time-to-repair  and  reduce  the 
number  of  NFE  repair  parts  turned  into  the  supply  system.  These  results  were 
encouraging. 

C.  THE  SECOND  EXPERIMENT 

The  idea  for  the  second  experiment  evolved  from  discussions  about  how  Navy 
training  might  change  in  the  future.  Driven  by  smaller  budgets,  high  training  costs,  and 
unacceptable  attrition  rates,  the  search  for  a  new  approach  to  training  has  begun.  One 
new  approach  suggests  that  “Just-in-Time”  training  may  be  the  way  to  cut  costs  and 
combat  high  attrition  rates.  Without  going  into  detail,  instead  of  emphasizing  formal 
classroom  training,  this  approach  relies  on  focused  job  specific  training  for  sailors  on  how 
to  perform  their  jobs  and  a  job  performance  aid  (e.g.  expert  system)  available  aboard  ship 
to  assist  in  maintenance. 

Viewing  MAES  as  a  “job  performance  aid”  for  the  MK  92  Mod  2  FCS,  Professor 
McCaffrey  proposed  that  fire  control  technicians  who  were  just  starting  the  MK  92  Mod  2 
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FCS  “C”  school  be  taken  into  the  lab  and  given  a  troubleshooting  problem  using  MAES. 
The  idea  was  to  see  how  the  students  performed  without  the  benefit  of  the  32  week 
school. 

For  the  actual  experiment,  FTC  instructors  chose  students  who  were  from  the 
Phalanx  Close-In  Weapons  System  class.  These  students,  like  the  MK  92  Mod  2  FCS 
students,  have  an  electronics  background  and  a  general  knowledge  of  test  equipment  (“A” 
school).  The  test  groups  had  no  prior  experience  with  MK  92  Mod  2  FCS. 

Using  MAES,  the  first  group  of  students  successfully  isolated  the  test  fault  in 
about  25  minutes.  The  normally  allotted  time  for  this  fault  was  45  minutes.  Two  other 
groups  followed  with  similar  results.  The  use  of  control  groups  was  considered  but 
dismissed  because  the  control  groups  would  have  no  point  of  reference  to  begin  their 
troubleshooting  efforts. 

The  findings  seem  to  suggest  that  a  basic  electronics  background  combined  with  a 
tool  like  MAES  might  reduce  the  required  training  time  in  “C”  school  for  new  technicians 
but  allow  them  to  function  at  an  equivalent  level  of  expertise.  Further  tests  and  analysis  of 
the  training  syllabus  are  needed  to  substantiate  this  claim. 
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APPENDIX  B:  IMPLEMENTATION  PLAN  FOR  DEPLOYING  MAES  TO  ATT. 

MK  92  MOD  2  FCS  SHIPS 


This  appendix  provides  a  plan  for  deploying  the  production  version  of  MAES  to  all 
MK  92  Mod  2  FCS  ships.  This  implementation  plan  includes  a  brief  discussion  about  the 
implementation  factors  and  risks  that  will  likely  confront  the  MAES  deployment  team.  In 
most  cases,  this  plan  does  not  assign  specific  individuals  to  tasks  or  activities.  Assigning 
responsibilities  should  be  one  of  the  first  tasks  tackled  by  the  deployment  team. 

This  long-term  implementation  plan  should  be  viewed  as  a  working  document 
since  MAES  prototype  deployment  has  not  been  completed.  Applicable  sections  in  this 
implementation  plan  should  be  changed  based  on  the  “lessons  learned”  from  the 
deployment  of  the  MAES  prototype. 
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MAES  IMPLEMENTATION  PLAN 

1.  Scope.  This  implementation  plan  covers  the  deployment  of  the  production  version  of 
the  Maintenance  Advisor  Expert  System  (MAES)  to  all  MK  92  Mod  2  Fire  Control 

System  (FCS)  ships.  The  homeports  include  Mayport,  Pascagoula,  Norfolk,  San  Diego 
Pearl  Harbor,  and  Yokosuka.  w 

1.1  Identification.  MAES  is  a  diagnostic  tool  that  assists  fire  control  technicians 
in  isolating  faults  occurring  in  the  MK  92  Mod  2  FCS.  The  current  version  of  the  MAES 
software  is  0.0X.  Your  version  of  the  software  can  be  verified  by  checking  the  front  label 
on  the  installation  diskettes,  by  viewing  the  label  at  the  bottom  of  the  program  icon,  or  by 
starting  the  program  and  checking  the  top  bar  on  the  introductory  screen. 

1.2  System  Overview.  The  purpose  of  MAES  is  to  put  expert  knowledge  for 
diagnostics  at  the  fingertips  of  shipboard  fire  control  technicians.  A  cost/benefit  study 
conducted  early  in  the  project  s  history  showed  that  this  expert  knowledge  could  decrease 
the  time  it  takes  to  isolate  a  fault  and  reduce  the  number  of  No-Fault  Evident  (NFE)  repair 
parts  selected  by  technicians. 

Relying  on  the  engineering  expertise  of  the  Naval  Surface  Warfare  Center,  Port 
Hueneme  Division  (NSWC  PHD),  the  Naval  Postgraduate  School  (NPS)  managed  the 
development  of  the  MAES  software.  Funding  for  the  project  was  received  from 
NAVSEA  and  the  Naval  Science  Advisors  Program  (NSAP).  On  completion  of  the 
project,  NPS  transitioned  life  cycle  support  for  MAES  to  NSWC  PHD  in  March  1997 
(tentative). 

1.3  Document  Overview.  This  plan  provides  a  description  of  those  activities  and 
materials  that  are  needed  to  deploy  MAES  to  all  MK  92  Mod  2  FCS  ships.  The  purpose 
of  this  plan  is  to  frame  the  implementation  process  in  terms  of  important  implementation 
factors  and  project  risks  so  that  the  deployment  team  accomplishes  their  goal  of 
implementing  MAES  in  a  manner  that  promotes  success.  This  plan  is  unclassified. 

2.  Installation  Overview 

2.1  Description.  The  deployment  of  MAES  aboard  ships  involves  several 
progressive  phases.  An  introductory  phase  of  the  deployment  process  involves 
considering  the  implementation  factors  and  risks  that  might  influence  the  success  of  the 

project.  Implementation  factors  such  as  user’s  perception  of  computing 
technology,  user  involvement  in  expert  system  implementation,  supervisor  support,  and 
user  perception  of  change,  have  all  been  identified  as  being  highly  important 
implementation  factors  for  expert  systems  similar  to  MAES. 

Along  with  these  implementation  factors,  project  risks  such  as  computer  literacy, 
various  levels  of  resistance,  chain-of-command  support,  and  successful  deployment 
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training  should  be  incorporated  in  planning  for  the  future  implementation  phases.  As 
simple  guidelines,  the  deployment  team  should: 

•  Be  sensitive  to  the  widely  varying  computer  skills  they  are  likely  to  encounter. 

•  Solicit  and  build  support  for  MAES  at  all  levels  of  the  chain-of-command. 

•  Cultivate  a  positive  relationship  with  the  FTSC  representatives. 

•  Focus  on  cultivating  supportive  “perceptions  of  change”  at  all  levels  of  the 
chain-of-command. 

•  Realize  that  deployment  training  is  a  Class  HI  risk  and  they  should  not  be 
deceived  by  its  apparent  simplicity. 

•  Understand  the  importance  of  an  effective  marketing  campaign  when  fielding 
MAES. 

The  first  phase  entails  formally  establishing  the  long-term  support  infrastructure 
and  communications  channels. 

The  second  phase  involves  gaining  the  appropriate  approval  from  the  chain-of- 
command  for  the  software  to  be  deployed  aboard  ships.  This  will  require  liaison  between 
the  deployment  team,  NSWC  PHD,  the  fleet  commanders’  staffs,  and  the  type 
commanders’  staffs.  The  deployment  team  should  view  the  approval  message  as  a 
marketing  tool  and  as  such  should  provide  sample  drafts  to  the  type  commanders’  staffs 

The  third  phase  involves  scheduling  and  should  commence  two  quarters  prior  to 
the  desired  implementation  dates.  Factors  such  as  busy  ships’  schedules  combined  with 
six  different  homeport  locations  will  make  the  scheduling  process  one  of  the  more 
complex  tasks  for  the  deployment  team. 

The  fourth  phase  involves  conducting  implementation  training  and  the  last  phase 
involves  providing  life  cycle  support. 

2.1.1  Installation  sites.  Twenty-eight  ships  homeported  in  six  different 
locations  are  tentatively  slated  to  receive  MAES.  The  type  commanders’  should  specify 
which  ships  will  receive  MAES  in  their  approval  message.  The  approval  message  should 
task  each  ship  to  provide  the  deployment  team  with  primary  and  secondary  installation 
dates,  a  point  of  contact  for  installation  arrangements,  and  a  phone  number.  The  number 
of  ships  may  change  based  on  decommissionings,  foreign  military  sales,  and  the  number  of 
prototype  sites. 

2.1.2  Installation  Dates.  The  installation  dates  are  undetermined. 

2.1.3  Method  of  Installation.  Preferably  site  visit  but  undetermined.  The 
method  of  installation  is  directly  related  to  the  various  deployment  training  options.  The 
potential  training  alternatives  include: 
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•  On-site  training  by  a  deployment  team  from  NSWC. 

•  On-site  training  by  FTSC  representatives. 

•  Training  by  a  deployment  team  at  a  central  site  such  as  the  training 
centers. 

•  Training  at  a  central  site  in  each  homeport  using  video-teleconferencing 
capabilities. 

•  Videotaped  training  with  videotapes  and  a  deployment  kit  (laptop 
loaded  with  MAES  software,  user’s  manuals,  etc.)  mailed  to  the  ships. 

•  Written  training  and  a  deployment  kit  mailed  to  the  ships. 

•  For  deployed  ships,  written  training  and  a  deployment  kit  could  be 
mailed  with  a  follow-up  visit  performed  by  NSWC  or  FTSC  when  the 
ships  return  to  their  homeport. 

2.2  Contact  Point.  The  contact  points  for  this  installation  are: 

Henry  Seto,  Project  Engineer 

Area  Defense  Systems  Engineering  Department 

Naval  Surface  Warfare  Center,  Port  Hueneme  Division 

Code  4W32 

4363  Missile  Way 

Port  Hueneme,  California  93043 

Phone:  (805)982-0141  DSN  551- 

e-mail:  Seto_Henry/4W00_AreaDefSysEngDept@om.nswses.navy.mil 

Professor  Martin  J.  McCaffrey 

Systems  Management  Curricular  Office  (Code  36) 

Naval  Postgraduate  School 
555  Dyer  Road,  Room  220 
Monterey,  CA  93943-5104 
Phone:  (408)656-2488  DSN  878- 
e-mail:  mjmccaff@nps.navy.mil 

2.3  Support  Materials. 

□  Prepackaged  user’s  manuals  for  bundled  software  such  as 
Microsoft®  Windows  and  DOS  6.2. 

□  Laptop  computer  preloaded  with  MAES. 

□  User’s  manual  for  the  laptop  computer. 

□  Two  copies  of  MAES  software  diskettes.  Version  0.0X. 

MAES  installation  instructions. 
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MAES  user’s  manual. 

Procedures  for  obtaining  software  updates,  submitting  change 
proposals  or  reporting  errors. 

Procedures  for  receiving  help. 

2.4  Training.  Based  on  information  gathered  from  the  deployment  of  the  MAES 
prototype,  this  section  should  discuss  the  plans  for  training  shipboard  fire  controlmen. 
This  section  should  discuss  a  general  orientation  for  both  the  software  and  hardware, 
classroom  training  (if  required),  and  “hands-on”  training. 

2.5  Tasks.  A  general  description  of  the  tasks  required  to  deploy  MAES  to  the 

ships  and  the  responsible  organization  or  person  is  provided  below: 

a.  Project  Engineer  from  NSWC  PHD  will  prepare  the  requests  for 
authority  to  deploy  MAES  to  the  respective  type  commanders. 

b.  Project  Engineer  from  NSWC  PHD  will  draft  recommended  inputs  to 
the  type  commanders’  approval  message. 

c.  Project  Engineer  from  NSWC  PHD  will  create  a  list  of  prospective 
installation  sites  and  dates  for  submission  to  the  applicable  scheduling  conference.  Access 
to  Atlantic  Fleet  ships  is  gained  through  scheduling  conference  inputs.  Access 
requirements  for  Pacific  Fleet  ships  may  differ. 

d.  NPS  will  create  a  MAES  marketing  campaign  which  will  include 
providing  educational  information  to  various  commands  and  publishing  articles  in 
periodicals  such  as  Surface  Warfare  or  Proceedings. 

e.  The  overall  planning,  coordination,  and  preparation  for  the  installation 
visits  will  be  the  responsibility  of  (staff  representative)  from  COMNAVSURLANT,  (staff 
representative)  from  COMNAVSURPAC,  and  the  project  engineer  from  NSWC  PHD. 

f-  The  installation  team  will  be  comprised  of  at  least  one  engineer  from 

NSWC  PHD. 


□ 

□ 

□ 


g.  Project  Engineer  from  NSWC  PHD  will  ensure  that  all  documentation 
applicable  to  the  implementations  is  available  prior  to  the  installation  dates. 
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h.  Project  Engineer  from  NSWC  PHD  will  ensure  that  all  hardware  and 
peripheral  devices  are  available  for  transfer  on  the  installation  date. 

i.  Project  Engineer  from  NSWC  PHD  will  plan,  coordinate,  and  conduct 
training  as  required. 

j.  (Ships’  point-of-contact)  will  ensure  that  designated  fire  controlmen  are 
available  and  attend  MAES  implementation  training.  This  individual  will  also  arrange  an 
orientation  briefing  for  the  Commanding  Officer  and  other  interested  command  personnel. 

k.  Project  Engineer  from  NSWC  PHD  will  conduct  post-implementation 
follow-up  calls. 

Note:  NPS  faculty  and  student  participation  may  occur  depending  on  tasldng. 

2.6  Security  and  privacy.  Since  this  software  is  unclassified,  special  security 
procedures  will  not  be  required  to  protect  MAES.  The  pilferable  nature  of  the  laptop 
computer  will  make  it  necessary  to  immediately  serialize  it  and  either  include  it  on  the 
applicable  command’s  controlled  equipage  inventory  or  test  equipment  inventory. 

3.  Site  Specific  Information.  This  section  provides  a  template  for  tracking 
implementation  related  information  specific  to  each  ship.  This  section  assumes  adoption 
of  an  on-site  implementation  strategy. 


3.1  Site,  Schedule,  and  Contact  Matrix. 


Ship 

Point  of  Contact 

Phone  # 

Primary 
Install  date 

Secondary 
Install  Date 

3.2  Implementation  Visit  Tasks.  This  section  outlines  the  schedule  of  tasks  to 
be  accomplished  during  the  installation.  Some  items  may  change  or  items  may  be  added 
based  on  the  NSAP  evaluation  deployment.  This  schedule  should  be  presented  as  a  Plan 
of  Action  and  Milestones  (POA&M)  listing  tasks  in  chronological  order.  Some  of  the 
activities  that  should  be  included  are: 
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•  T- 120.  Provide  scheduling  conference  inputs. 

•  T-90.  Order  laptops/surge  protectors/cases. 

•  •  Contact  ships  scheduled  for  installations.  Establish  points-of-contact 
and  determine  primary/secondary  installation  dates. 

•  T-14.  Ensure  that  the  laptops  and  supporting  peripherals  are  available.  If 
shipping  computers,  ensure  that  MAES  software  is  preloaded  and  allow  two 
weeks  lead  time  for  shipping. 

•  T-14.  Load  MAES  software  onto  the  laptop  and  test. 

•  T-14.  Assemble  all  training  materials  and  support  documentation. 

•  T-7.  Confirm  all  arrangements  one  week  prior. 

•  T-3.  Confirm  security  clearances  have  been  received  by  ship. 

•  Conduct  in-brief  with  the  Commanding  Officer  and  designated  officers,  chief 
petty  officers,  and  work  center  representatives. 

•  Conduct  computer  orientation  training. 

•  Conduct  MAES  software  orientation  training 

•  Review  all  provided  materials  including  user’s  manual  for  the  hardware  and 
software. 

•  Review  special  procedures  for  getting  help,  completing  trouble  reports, 
submitting  error  reports,  etc. 

•  Conduct  out-brief  with  the  Commanding  Officer  and  designated  officers,  chief 
petty  officers,  and  work  center  representatives  as  necessary. 

•  T+14.  Conduct  follow-up  survey  by  phone  or  SALTS. 

3.3  Facilities.  This  section  will  describe  the  physical  facilities  and 
accommodations  needed  to  support  implementation  training.  This  task  will  become 
important  if  the  implementation  training  is  held  some  place  other  than  on  the  ship. 

Lessons  learned  from  the  NSAP  deployment  and  evaluation  will  provide  valuable  details. 
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APPENDIX  C:  INTEGRATION  PLAN  FOR  INCLUDING  MAES  IN  THE  MK  92 
MOD  2  FCS  “C”  SCHOOL  CURRICULUM 


This  appendix  provides  a  plan  for  integrating  MAES  into  the  MK  92  Mod  2  FCS 
“C”  School  curriculum.  The  integration  plan  includes  a  brief  discussion  about  the 
implementation  factors  and  risks  that  will  likely  confront  the  MAES  deployment  team.  In 
most  cases,  this  plan  does  not  assign  specific  individuals  to  tasks  or  activities.  Assigning 
responsibilities  should  be  one  of  the  first  tasks  tackled  by  the  deployment  team. 
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MAES  INTEGRATION  PLAN 


1.  Scope.  This  integration  plan  covers  the  formal  integration  of  the  Maintenance 
Advisor  Expert  System  (MAES)  into  the  MK  92  Mod  2  Fire  Control  System  (FCS)  “C” 
school  curriculum.  This  plan  includes  the  fleet  training  centers  in  Dam  Neck,  Virginia  and 
San  Diego,  California. 

1.1  Identification.  MAES  is  a  diagnostic  tool  that  assists  fire  control  technicians 
in  isolating  faults  occurring  in  the  MK  92  Mod  2  FCS.  The  current  version  of  the  MAES 
software  is  0.0X.  Your  version  of  the  software  can  be  verified  by  checking  the  front  label 
on  the  installation  diskettes,  by  viewing  the  label  at  the  bottom  of  the  program  icon,  or  by 
starting  the  program  and  checking  the  top  bar  on  the  introductory  screen. 

1.2  System  Overview.  The  purpose  of  MAES  is  to  put  expert  knowledge  at  the 
fingertips  of  shipboard  fire  control  technicians.  A  cost/benefit  study  conducted  early  in  the 
project  s  history  showed  that  this  knowledge  could  decrease  the  time  it  takes  to  isolate  a 
fault  and  reduce  the  number  of  No-Fault  Evident  (NFE)  repair  parts  selected  by 
technicians. 

Relying  on  the  engineering  expertise  of  the  Naval  Surface  Warface  Center  Port 
Hueneme  Division  (NSWC  PHD),  the  Naval  Postgraduate  School  (NPS)  managed  the 
development  of  the  MAES  software.  Funding  for  the  project  was  received  from 
NAVSEA  and  the  Naval  Science  Advisors  Program  (NSAP).  On  completion  of  the 

project,  NPS  transitioned  life  cycle  support  for  MAES  software  to  NSWC  PHD  in  March 
1997  (tentative). 

1.3  Document  Overview.  This  plan  provides  a  description  of  those  activities  and 
materials  that  are  needed  to  integrate  MAES  into  the  MK  92  Mod  2  FCS  “C”  school 
curriculum.  The  purpose  of  this  plan  is  to  frame  the  integration  process  in  terms  of 
important  implementation  factors  and  project  risks  so  that  the  deployment  team 
accomplishes  their  goal  of  implementing  MAES  in  a  manner  that  promotes  success.  This 
plan  is  unclassified. 

2.  Installation  Overview 

Description.  A  standard  implementation  process  might  begin  with  an 
introduction  to  the  system  supported  by  familiarization  training.  This  step  will  not  be 
necessary  for  the  integration  of  MAES  into  the  MK  92  Mod  2  FCS  “C”  school  curriculum 
because  of  the  prior  experience  that  the  training  centers  have  with  MAES.  Instead,  this 
implementation  process  will  focus  on  post-implementation  support  issues  which  are 
important  to  the  long-term  viability  of  MAES. 

To  set  the  stage,  the  deployment  team  should  review  those  implementation  factors 
and  risks  that  might  influence  the  success  of  the  MAES  project.  Implementation  factors 
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such  as  user’s  perception  of  computing  technology,  user  involvement  in  expert  system 
implementation,  supervisor  support,  and  user  perception  of  change,  have  all  been 
identified  as  being  highly  important  implementation  factors  for  expert  systems  similar  to 
MAES.  Along  with  these  implementation  factors,  project  risks  such  as  training  center 
acceptance  and  advocacy,  chain-of-command  support,  and  deployment  training  should  be 
given  careful  consideration. 

As  simple  guidelines,  the  deployment  team  should: 

•  Emphasize  to  the  training  centers’  instructors  the  importance  of  building 
positive  perceptions  of  this  technology  in  the  opinions  of  the  students. 

•  Describe  to  the  instructors  how  their  support  and  involvement  are  important. 

•  Understand  that  with  the  training  centers  there  are  actually  two  groups  of 
users,  the  students  and  the  instructors. 

•  Focus  on  cultivating  supportive  “perceptions  of  change”  on  the  part  ofthe 
instructors. 

•  Realize  that  deployment  training  is  a  Class  m  risk  and  they  should  not  be 
deceived  by  its  apparent  simplicity. 

•  Understand  the  importance  of  an  effective  marketing  campaign  when  fielding 


2.1.1  Installation  sites.  The  two  training  centers’  addresses  and  points  of 

contact  are: 


Fleet  Combat  Training  Center  Atlantic,  Dam  Neck 
Code  N723C 

Weapons  Training  Department 
1912  Regulus  Avenue 
Virginia  Beach,  Virginia  23461-2098 
Points  of  contact:  LT  Tommy  Johnson 

(804)433-6351  DSN  433- 
(804)  433-7492  (fax) 
or 

FCC(SW)  Ken  Turman 

(804)  433-6691  or  e-mail 

FCTCLANT.N7 23 TKD@netpmsa.  cnet .  navy .  mil 


Fleet  Training  Center 

Box  368035,  FLEETTRACEN  Code  424 
3975  Norman  Scott  Road,  Suite  1 
San  Diego,  CA  92136-5588 
Point  of  contact:  FCC(SW)  Myers 

(619)  556-7577  DSN  526- 
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2.1.2  Installation  Dates.  The  installation  dates  are  undetermined. 

2.1.3  Method  of  Installation.  Site  visit. 

2.2  Contact  Point.  The  contact  points  for  this  installation  are: 

Henry  Seto,  Project  Engineer 

Area  Defense  Systems  Engineering  Department 

Naval  Surface  Warfare  Center,  Port  Hueneme  Division 

Code  4W32 

4363  Missile  Way 

Port  Hueneme,  California  93043 

Phone:  (805)982-0141  DSN  551- 

e-mail:  Seto_Henry/4W00_AreaDefSysEngDept@om.nswses.navy-mil 

Professor  Martin  J.  McCaffrey 

Systems  Management  Curricular  Office  (Code  36) 

Naval  Postgraduate  School 
555  Dyer  Road,  Room  220 
Monterey,  CA  93943-5104 
Phone:  (408)  656-2488  DSN  878- 
e-mail:  mjmccaff@nps.navy.mil 

2.3  Support  Materials. 

FI  Prepackaged  user’s  manuals  for  bundled  software  such  as 
Microsoft®  Windows  and  DOS  6.2. 

[  [  Laptop  computers. 

|~~~j  User’s  manual  for  the  laptop  computer. 

□  MAES  software  diskettes.  Version  0.0X 

[  |  MAES  installation  instructions. 

□  Laptop  compatible  overhead  projector. 

|  [  A  copy  of  MAES  knowledge  diagnostic  trees. 

|  |  Procedures  for  obtaining  software  updates,  submitting  change 
proposals  or  reporting  errors. 
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2.4  Training.  Training  will  focus  on  familiarizing  the  fleet  training  centers’ 
instructors  with  the  various  support  materials  described  above.  General  orientation 
training  and  other  forms  of  introductory  training  for  first  time  users  will  not  be  required  at 

the  fleet  training  centers  unless  key  training  center  contacts  detach  prior  to  the  scheduled 
installations; 

2.5  Tasks.  A  general  description  of  the  tasks  required  to  deploy  MAES  to  the 

training  centers  and  the  responsible  organization  or  person  is  provided  below: 

a-  The  overall  planning,  coordination,  and  preparation  for  the  installation 
will  be  the  responsibility  of  the  project  engineer  from  NSWC  PHD,  Chief  Petty  Officer 
Myers  from  FTC,  San  Diego,  and  Chief  Petty  Officer  Turman  from  FCTC,  Dam  Neck. 

b.  The  installation  team  will  be  comprised  of  at  least  one  engineer  from 
NSWC  PHD.  NPS  faculty  and  student  participation  may  apply. 

c-  Project  engineer  from  NSWC  PHD  will  ensure  that  all  documentation 
applicable  to  the  implementations  are  available  prior  to  the  installation  dates. 

d.  Project  engineer  from  NSWC  PHD  will  ensure  that  all  hardware  and 
peripheral  devices  are  available  for  transfer  on  the  installation  date. 

e.  Project  engineer  from  NSWC  PHD  will  plan  and  conduct  training  as 

required. 


f.  Chief  Myers  and  Chief  Turman  will  identify  those  instructors  who  will 
receive  MAES  training  at  their  respective  training  centers. 

2.6  Security  and  privacy.  Since  this  software  is  unclassified,  special  security 
procedures  will  not  be  required  to  protect  MAES.  The  pilferable  nature  of  the  laptop 
computer  will  make  it  necessary  to  immediately  serialize  it  and  include  it  on  the  applicable 
command’s  minor  property  inventory. 

Note:  NPS  faculty  and  student  participation  may  occur  depending  on  tasking. 
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APPENDIX  D:  MAES  SYSTEM  LEVEL  DESCRIPTION 


The  MAES  system  level  description  provides  data  that  will  be  used  to  maintain  the 
system.  It  will  include  a  brief  overview  of  the  system’s  purpose,  the  system  development 
environment,  the  target  operational  environment,  the  system  architecture,  and  resulting 
products.  As  mentioned  in  Chapter  V,  the  system  level  description  is  one  of  four 
documentation  products  that  will  be  developed  for  MAES.  Information  from  these 
documents  will  be  integrated  into  a  Software  Transition  Plan  when  all  of  the  documents 
have  been  completed. 

This  is  an  initial  outline  for  the  system  level  description.  Improvements  to  this 

\  . 

document  should  be  made  as  additional  information  about  the  production  version  of  the 
MAES  software  becomes  available.  Information  contained  in  this  document  has  been 
drawn  from  a  number  of  sources.  Lawrence  Scruggs,  the  software  engineer  for  the 
Calibration  module,  provided  the  majority  of  the  information  comprising  this  system  level 
description.  The  deliverable  document  will  be  developed  as  part  of  the  production  funded 
tasking. 
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MK  92  Mod  2  Fire  Control  System 
Maintenance  Advisor  Expert  System 
(MAES) 


SYSTEM  LEVEL  DESCRIPTION 


Prepared  By 

Naval  Postgraduate  School 
Monterey,  California 

Prepared  For 

Naval  Surface  Warfare  Center 
Port  Hueneme  Division 


13  September  1996 


I.  Document  Scope. 

A.  System  Applicability.  The  Maintenance  Advisor  Expert  System(MAES)  is  a 
diagnostic  expert  system  designed  to  provide  training  and  troubleshooting  assistance  to 
fire  control  technicians  who  maintain  the  MK  92  Mod  2  Fire  Control  System  (FCS) 
installed  aboard  U.S.  Navy  Oliver  Hazard  Perry  class  guided  missile  frigates. 

B.  The  purpose  of  this  document  is  to  describe  the  purpose  of  MAES,  its 
development  environment,  the  overall  system  architecture,  and  the  products  which  form 
MAES. 

II.  Applicable  Documentation. 

A.  List  of  MIL  Specs  used  (if  any)  -  None 

B.  List  of  government  documents  used  -  None 

C.  List  of  commercial  documents  used  -  Will  be  available  after  the  integration  of 
the  performance  and  calibration  modules. 

in.  System  Overview. 

A.  Development  Rationale.  Repeatedly  listed  on  the 
CINCLANTFLT/CINCPACFLT  Fleet  Troubled  Combat  Systems  Reports,  the  MK  92 
Mod  2  FCS  is  a  maintenance  intensive  system  that  is  plagued  by  excessive  downtime  and 
often  requires  outside  technical  assistance  to  repair.  MAES  attempts  to  provide 
shipboard  Fire  Control  technicians  with  access  to  expert  knowledge  and  troubleshooting 
expertise  through  a  software  program. 

B.  Purpose  of  MAES.  The  main  purpose  for  developing  MAES  is  to  enhance  the 
ability  of  MK  92  Mod  2  Fire  Control  technicians  to  better  determine,  diagnose,  and 
resolve  problems  occurring  within  their  systems  without  the  assistance  of  outside  technical 
representatives.  (McGaha,  1994)  While  MAES  provides  diagnostic  capabilities,  it  is  not 
integrated  into  the  MK  92  Mod  2  FCS  and  is  best  deployed  on  a  standalone  laptop 
computer. 

C.  Development  Environment. 

1.  Naval  Postgraduate  School  computer  laboratory  provides  access  to 
research  and  commercial  software  and  hardware.  Provided  resources  include  internet 
access  to  support  tools  such  as  software  updates. 

2.  Commercial  Expert-System-Development  Shell  (Integrated 
Development  Environment  or  IDE). 
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a)  Terms  used  to  describe  the  IDE  and  “programming  language” 
include  “graphical  programming,”  “visual  programming,”  and  “iconic  programming.” 
One’s  first  visual  impression  might  remind  one  of  formal  structure  charts  used  in  software¬ 
engineering  documentation. 

b)  MAES  is  currently  two  application  files  (Calibration  and 
Performance)  each  containing  sets  of  procedures.  Each  procedure  is  a  set  of  nodes  and 
arcs  assembled  to  provide  assistance  in  troubleshooting  specific  areas  of  the  MK  92  Mod 
2  FCS.  The  procedures  generally  follow  the  troubleshooting  structure  charts  provided  by 
the  expert. 


c)  Nodes  and  arcs  (represented  in  the  IDE’s  GUI  by  icons  and 
colored  lines)  do  the  work  of  traditional  declarative  and  procedural  code  lines  (as  in  Ada, 
C,  Pascal,  FORTRAN,  SAS,  etc.). 

(1)  Nodes  represent  reusable  “packages”  of  code  that 
generate  CRT  displays  and  accept  user  input,  make  decisions  based  on  user-provided  data 
and  rules  provided  by  experts,  and  link  procedures. 

(2)  Arcs  represent  program-control  flow. 

(3)  Data  flow  is  not  represented. 

3.  Personal  Computer  compatible  desktop  computer. 

a)  Intel  80486  compatible,  50  MHz,  8  MB  RAM,  150  MB  hard 
drive,  100  MB  Iomega  Zip  drive,  Hewlett  Packard  Laseijet  IIP  printer. 

b)  Intel  80586  compatible,  100  MHz,  16  MB  RAM. 

4.  Support  tools. 

a)  The  internet  provides  communication  among  team  members  and 
access  to  maintenance  items  for  development  tools. 

b)  MS-Office  provides  administrative  and  documentation  support. 

c)  Image  management  relies  on  COTS  software. 

D.  Description  of  Target  Operational  Environment.  Personal  Computer 
compatible  laptop  computer. 
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drive. 


1.  Intel  80486/80586  compatible,  100  MHz,  16  MB  RAM,  500  MB  hard 


2.  MAES  Calibration  and  Performance  modules  currently  require  20 
megabytes  of  disk  space.  These  modules  can  run  in  eight  megabytes  of  RAM. 

E.  Description  of  System  Architecture.  The  main  Adept  constructs  are 
applications,  procedures,  and  nodes/arcs.  An  application  usually  consists  of  several 
procedures,  where  each  procedure  is  made  up  of  nodes,  displays,  variables,  and  functions. 
An  application  typically  corresponds  to  the  overall  program.  (Smith,  1994) 

Programs  called  procedures  are  used  to  build  an  application.  A  procedure  consists 
of  a  series  of  visual  objects  called  nodes.  A  node  is  a  graphical  object  which  represents  a 
specific  step  or  series  of  steps  within  any  given  procedure.  It  is  a  visual  object  that  allows 
end  users  to  design  and  implement  an  expert  system  without  having  to  deal  with 
traditional  text-based  programming  code.  (Smith,  1994) 

The  MAES  program  would  be  considered  an  application.  Procedures  supporting 
the  application  would  presently  be  structured  around  two  modules,  the  performance 
module  and  the  calibration  module.  Nodes  representing  yes/no/unknown  decisions  are 
used  to  build  procedures  which  are  drawn  from  the  domain  expert’s  knowledge  document. 

F.  Description  of  Validation  Methodology.  Validation  has  been  performed 
through  visual  inspection  of  the  product  by  experts  and  the  target  audience. 

G.  Description  of  MAES  products.  Loaded  on  a  laptop  computer,  MAES 

software  provides  MK  92  Mod  2  FCS  technicians  access  to  expert  knowledge  to  assist 
them  in  isolating  faults  discovered  during  MK  92  Mod  2  FCS  Daily  Systems  Ooerabilitv 
Tests  (DSOT).  K  y 

IV.  Development  Environment 

A.  Hardware  Requirements.  Personal  Computer  compatible  desktop  computer. 

1.  Intel  80486  compatible,  50  MHz,  8  MB  RAM,  150  MB  hard  drive,  100 
MB  Iomega  Zip  drive,  Hewlett  Packard  Laseijet  IIP  printer. 

2.  Additional  computers  are  used  for  communications  and  demonstrations 
in  support  of  the  project. 

B.  Software  Environment.  The  software  environment  for  MAES  includes 
Microsoft  DOS®  6.2  and  Microsoft  Windows®  3.1. 

C.  Software  tools  which  are  MAES  (or  expert  system)  specific.  SoftSell  Adept® 
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V.  Target  Operational  Environment 

A.  Hardware  Requirements.  Intel  80586  compatible,  100  MHz,  16  MB  RAM. 

B.  Software  Environment.  The  user  must  interface  through  three  levels  of 
software  -  DOS,  Windows,  and  Adept  -  to  operate  MAES. 

VI.  System  Architecture 

A.  Basic  System  Structure.  (Should  show  how  the  different  software  units 
interface  with  each  other.  Need  to  list  everything  required  to  run  MAES  including  the 
operating  system,  commercial  software  packages,  databases,  etc.) 

B.  Structure  of  all  units  developed  specifically  for  MAES.  (Internal  organization, 
data  type  requirements,  unit  interactions.) 

VII.  Validation  Methodology 

A.  What  type  of  validation  is  planned? 

B.  Scope  of  validation. 

C.  Location,  schedule,  equipment  requirements,  and  personnel  requirements. 

VIII.  Products 

A.  Documentation  developed  for  MAES 

1 .  System  Level  Description 

2.  Software  Design  Document 

3.  MAES  User’s  Manual 

4.  Version  Description  Document 

B.  Software  developed  for  MAES 


106 


APPENDIX  E:  FORMS 


This  appendix  contains  three  existing  forms  or  reports  that  can  be  adapted  to 
support  MAES  reporting  procedures.  Use  of  these  forms  will  take  advantage  of  existing 
reporting  channels  and  procedures  rather  than  creating  new  ones.  These  forms  include  the 
NSWC  PHD  Software  Trouble  Report,  the  Digital  Systems  Feedback  Report  (NSWSES- 
3142/1),  and  the  Engineering  Change  Proposal  (DD  Form  1692).  The  function  of  these 
forms  is  described  in  Chapter  III  and  summarized  below: 

NSWC  PHD  Software  Trouble  Report  (STR):  The  STR  should  be  used  mainly  by 
engineers  who  are  familiar  with  the  MAES  software  and  the  MK  92  Mod  2  FCS  to  report 
software  problems  or  to  propose  software  enhancements. 

Digital  Systems  Feedback  Report  (DSFR):  The  DSFR  serves  the  same  purpose  as 
the  STR  but  it  uses  a  simpler  format.  The  DSFR  is  primarily  intended  for  use  by  sailors 

and  support  personnel  to  report  software  errors,  submit  trouble  reports,  or  recommend 
enhancements. 

Engineering  Change  Proposals  (ECPs):  Open  SFR’s  are  periodically  reviewed  by 
the  Software  Configuration  Control  Board  and  rewritten  as  ECPs.  Certain  ECPs  are 
selected  for  a  software  build  referred  to  as  a  version  release. 
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NSWC  PHD  SOFTWARE  TROUBLE  REPORT 
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T0:  b„mon.  Naval  Surfta  Warfare  Center ' 


JPort  Hueneme,  California  93043 

■g^SSCSS  I  !■ 


6.  Official  Program  Designation 

7.  Official  Program  Document 

8,  Unit/Si te 

ya~  ito gram  Mcomm  9b.  Serial  No. 

10.  Reference  Document 

11.  Function  Affected 

“*  “qraalDB  MOQluC\S)  ' 

13.  Tett/Step 

*“•  viiguijnor 

15.  Activity/Code 

^16.  Tel/Hxt 

*  «  ♦  ftUM  tngjg 

20.  Configaration/PAtchcs  in  Core 

18.  Simulation  Used 

19.  Interface  with 

21.  Problem  Dupliaued  -  Circle  the  required  items 

22a.  Enclosures-  Circle  the  required  items 

22b.  Other  Systems/Programs  Affected 

During  Run  Yes  No  N/A 

After  Restart  Yes  No  N/A 

After  Reload  Yes  No  N/A 

23.  Trouble  Description 

Complication 
Sample  Program 
Object  Program 
Source  Program 

Typewriter  O/P 
Memory  Map 
Memory  Dump 
Other 

24.  Response 


Valid 

25  V&V  Dam 

Urgency 

ECP  Class 

ECP  Number  — "  ' 

▼  a.  t  i/atc 

26.  Navy  SCCB  Signature 

*  To  Be  Filled  In  By  Software  Support  Agent  Only 
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DIGITAL  SYSTEMS  FEEDBACK  REPORT 
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DIGITAL  SYSTEMS  FEEDBACK  REPORT  (DSFR) 


WAP  OKS  SYSTEM 

MK: 

SHIPBOARD  POINT  OF  CONTACT 


PHOHE  NUMBER  Oft  CONTACT  METHOD 


NUU  NUMBER 


OEUYtRY  TAPE  SERIAL  NUMBER 


QUESTION  OR  PROBLEM:  — 


•i'  SEND  COMPLETED  FORM  TO: 

COMMANDING  OFFICER 

engineering  station 

PORT  HUENEME,  CA  93043-5007 
ATTENTION  CODE  4W40  (CM) 


NSWSES  TARTAR  DEPARTMENT 
ATTENTION  4W40  (CM) 

FAX  NO.  (805)  982-8546 
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ENGINEERING  CHANGE  PROPOSAL 
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need  for  change 


1>.  ESTIMATED  KIT  oelivery  SCHEDULE 


37  1-OC»TIONS  W  SH.P/YeHlu.t  NUMBERS  AFFeCTED" 


a.  CLASS  I 

□IffROYAt 

LECAW  ENDED 

cV  GOVERNMENT  AttlvTTT- 


O—  □  OlfAffXmD  f  jCOKCU*  j«  CU«|- 

- -  I - 1  FtCATIOM  OF  CHANGE 


Si  GMATU ft£ 


□  W  HOT  COHCOK  Ik 

ClASSI FlCAT (OK  OF  CHANGE 


«.  OTHER  SYSTEMS  fFFCCTiQ 


EfFECTS  OK  FU^iONAt/AtUPCArED  CONFISURATI&n  IDENTIFICATION 

[Wi  OTHER  CCNTRACTCR£/ACn CITIES  AFFECTED" 


DD  1  occ*««  1692-1  S/N-0  102-0  20- 8010 


ft  U.S.  GOVERNMENT  PRINTING  OFFICE:  1*7  <-  Tl3-«53/  J**3  2-1 
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APPENDIX  F:  SOFTWARE  TRANSITION  PLAN 


This  appendix  provides  the  Software  Transition  Plan  (STrP)  Data  Item  Description 
(DID)  from  the  Department  of  Defense’s,  Software  Development  and  Documentation 
Military  Standard,  MIL-STD-498.  The  STrP  identifies  hardware,  software,  and  other 
resources  needed  for  life  cycle  support  of  deliverable  software.  It  also  describes  the 
developer’s  plans  for  transitioning  deliverable  items  to  the  support  agency.  In  the  case  of 
MAES  software,  the  deliverable  items  include  documents  such  as  the  System  Level 
Description,  the  Software  Design  Document,  the  MAES  user’s  manual,  and  the  Version 
Control  Document. 
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DATA  ITEM  DESCRIPTION 


Fotm  Approved 
OMBNO.07CUJUPS 

■*=*«- 


SOFTWARE  TRANSITION  PLAN  (STrP) 


UfcSCRIPTIOfM 


L1  J1’,6  Software  Transition  Plan  (STrPJ  identifies  the  hardware,  software,  and  other  resources  n^H  w 
Iten^ttaS^c* ,0^“’  *v'lope,'s  plans  ,or  deliverable 

rieLi^lL^I/ P  15  davak>ped  if  lhe  *ofw«re  support  concept  calls  for  transition  of  responsibilitv  from  the 

may  be  bv  ,h<  *  ■*** *■ 


V  APPROVAL  DATE 

Vfymw  941205 


6.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

205  Ec 

iJwTfeHHaATIONSHIP - - - - 


6«.  OTIC  APPLICABLE  I  60.  GIDEP  APPLICABLE- 


producloerwtratetrbv'scnSfic'an^rtswet^ta^^wparernen^as'deBnewwrai^th^Mntract00*  **  <*“ 

hi.1?  “aSSS '££!“  de”,l°'”r  “  K5k8d  “  d've",°  and  pla“  <«  tcnsltionm,  deliverable 

«“™J !  <°°  ’«3I  edould  specify  whether  deliverable  data  are  „ 
rAmn«»'ki  -  l  "  electronic  media,  are  to  be  m  a  given  electronic  form  (such  as  a^pii  pai  c 

7.4  This  DID  supersedes  DI-MCCR-80024A. 


8.  APPROVAL  LIMITATION  - 

Limi,»d  Approve  from  12/5/34  through  12/5/9S 
l6.  PREPARATION  iNSfRUCTIONS  - - - 

General  instructions. 


3«.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7072 


Automated  t« 
DID  means  a 


3SSS  Tha """  ■d““™™- 


i  1.  bisTAi&ut  i6n  statement - — - - - 

DISTRIBUTION  STATEMENT  A.  Approved  for  public 


(Continued  on  Page  2} 


DD  Form  1664,  APR  89 
135/123 


a  ror  public  release;  distribution  is  unlimited." 
PreviourvcDtions  are  obsolete  “ - ET" 


Page  J_  of  j>_  Pages 


ion  handling  Sctujck.  DCDSTD  Issue  95-01 


niL-STD-M*** 
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Software  Transition  Plan  (STrP) 

DI-1PSC-81429 

10.  PREPARATION  INSTRUCTIONS  ~  10.1  General  Instructions  (continued! 

c*  3j.tte  .P3ge  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to 
which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing 
organization;  and  distribution  statement.  For  data  in  a  database  or  other  alternative 
form,  this  information  shall  be  included  on  external  and  internal  labels  or  by  equivalent 
identification  methods. 


l3bte  Of  Contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to.  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 


e*  PflOS  numfrering/lgfrftling.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 


BgSPgnse  .to  titering  instructions.  If  a  paragraph  is  tailored  out  of  this  01 D.  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

jyffg  Paragraphs  end, subparagraph?-  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

Standard  sjajs  d??Qripti<?n$.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

'*  SubSt'tUfrpn  pf  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 


10,2.  f-pntent  requirements.  Content  requirements  begin  on  the  following  page  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 


Page  2  of  6 
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ton  Kindi  ino  S*rv>ic*<  nfTTTTT)  I oc-ni 


f!IL-ST]>-4«ifi  ■  WM11  047RS23  0 SI  M 
Software  Transition  Plan  (STrP) 

DI-IPSC-81429 

10.  PREPARATION  INSTRUCTIONS  -  10.2  Content  Requirements  (continued) 

1.  SfifiEfi.  This  section  shall  be  divided  into  the  following  paragraphs. 

1-1  idg.htifiggfion.  This  paragraph  shall  contain  a  full  identification  of  the  system  and  tho 

SSSribtolS?  *??  document  app,iQS'  deluding,  as  applicable,  identification  number^) 
title(s),  abbreviation(s),  version  number(s),  and  release  numbers).  '  ' 

1-2  System  gvprview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  and  the 
“S'™"10  which  «■  document  applies.  !,  shall  describe  the  general  nature  system 
“""'"rise  the  history  of  system  development.  Operation,  and  SS 
and  !lur^dPr0|*Ct  ?pon?or'  •“**»•  user,  developer,  and  support  agencies;  identify  current 

and  planned  operating  sites;  and  list  other  relevant  documents.  y  current 

d^nSS?111?  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 

ocument  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

sVtpfn'  °thPr  phn^~  This  para9raPh  shall  describe  the  relationship,  if  any  of  the 

STrP  to  other  project  management  plans.  y 

Ztotomeri  flora  fmnntfl.  This  section  shall  list  the  number,  title,  revision  and  date  of  »n 
documents  referenced  in  this  document.  This  section  shall  also  a 

uments  not  available  through  normal  Government  stocking  activities. 

?^ppnrt  rpsn,,rrpc-  This  section  shall  be  divided  into  paragraphs  to  identify  and 
describe  the  resources  needed  to  support  the  deliverable  software  ^ese  resour^h^ 

C0P'r- “nd distribute <h*  »oftw«.nd te d“umenm“„  a“ 

SJFT  Tt!‘S  para9raph  shal1  describe  the  facilities  needed  to  support  the  deliverable 

such  as  -£?ESr  mav mM,Ude  ^pecial  bui,dings' rooms'  mock-ups,  building  features 
sucn  as  raised  flooring  or  cabling;  building  features  to  support  security  and  „?«,!! 

equipment,  and  norycompute,  equipment.  The  description  swSideT  °  ^ 


a. 

b. 

c. 

d. 


Specific  models,  versions,  and  configurations 
Rationale  for  the  selected  hardware 

Reference  to  user/operator  manuals  or  instructions  for  each  item,  as  applicable 

ve.  an  item  the  support  agency  must  acquire,  or  other  description  of  status 
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10.  PREPARATION  INSTRUCTIONS -10.2  Content  Requirements  (continued) 


e. 


f. 


a. 

b. 

c. 


wh«thor^USt  be  acquired' information  about  a  current  source  of  supply,  includina 
the  time  otVeTery  CUrre"tlV  "”****  *  *  expected  to  be  available  at 

Ihl°itTm  fc"  Sb0Ut  r"anufacturer  support,  licensing,  and  data  rights,  including  whether 
the  .tern  is  currently  supported  by  the  manufacturer,  whether  it  is  exported  taE 
supported  at  the  time  of  delivery,  whether  licenses  will  be  assigned  totfie  support 
agency,  and  the  terms  of  such  licenses  PPOrt 

fl.  Security  and  privacy  considerations,  limitations,  or  other  items  of  interest 

3-3  Sffftwgrg.  This  paragraph  shall  identify  and  describe  the  software  and 
documematfon  needed  ,o  support  ,ho  definable  sofnvore.  Saro  iS 

SSf1™"  angineering  (CASE)  tools,  data  in  these  tools,  compilers,  test  tools 

rulat,ons-  “““*«•  configuration  management  tools  datSs 
data  files,  and  other  software.  The  description  shall  include:  ®S  and 

?ameS'  identificat'on  numbers,  version  numbers,  release  numbers  and 
configurations,  as  applicable  Ders,  and 

Rationale  for  the  selected  software 

Reference  to  user/operator  manuals  or  instructions  for  each  item,  as  applicable 

of  ®ach  software  item  and  document  as  acquirer-furnished,  an  item  that 
w,H  be  delivered  to  the  support  agency,  an  item  the  support  agency  is  known  to 
have,  an  item  the  support  agency  must  acquire,  or  other  description  of  sta?us 

"?us5  be  acquired.  information  about  a  current  source  of  supply  includino 

,rr:  STS currera,y  avai“e  -  *  >•  ?oVi™Z7, 

!"f°r'"a'ion  ab°ut  vendor  support,  licensing,  and  data  rights,  including  whether  the 
nem  is  currently  supported  by  the  vendor,  whether  it  is  expected  tobesupportedm 

™  s^'ss:she,har  -  *-  «««. 

Security  and  privacy  considerations,  limitations,  or  other  items  of  interest 

V  id,“tHy,anV  °,har  d— "ceded  to 

«=K»taS£S=S33sS=MS 

Names,  identification  numbers,  version  numbers,  and  release  numbers,  as  applicable 
Rationale  for  including  each  document  in  the  list 

01  ®aCh  document  as  acquirer-furnished,  an  item  that  will  be  delivered 
to  the  support  agency,  an  item  the  support  agency  is  known  to  have 
support  agancy  must  acquire,  o,  other  description  of  stams  mm  ,he 

If  a  document  must  be  acquired,  information  about  where  to  acquire  it 


9- 


a. 

b. 

c. 


d. 
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10.  PREPARATION  INSTRUCTIONS- 10.2  Content  Requirements  (continued) 

e.  Information  about  licensing  and  data  rights 

f.  Security  and  privacy  considerations,  limitations,  or  other  items  of  interest 

<3;L?:S0nnfL,ThiS  para0raph  shaU  describe  the  Personnel  needed  to  support  the  deliverable 
^  '  including  anticipated  number  of  personnel,  types  and  levels  of  skins  and  expertisi 

develooment  Thls  paragraPh  shal1  cite,  as  applicable,  actual  staffing  on  the 

development  project  as  a  basis  for  the  staffing  needs  cited. 

ddi  ,™,S  *,r“gr"ph  sha“  “»"«<*  “V  other  resources  needed  to  support  the 

,nclud8d  may  68  oonsumables  such  es  magnetic  tapes  and  diskettes 
together  with  an  estimate  ot  the  type  end  number  that  should  be  acquired. 

f'J  jmp're'at'Oqship  gf  components.  This  paragraph  shall  identify  the  interrelationshios  of 
toSS  in  *•  ■""*»  *  «9ure  may  be  used  ,~,he 

Hpgi^f0mfT>Sn^ft^^rgCe^urgl<?'  This  section  sha|1  be  divided  into  paragraphs  as  needed  to 
to  ecommlr^  0'65'  ind“din9  aduice  and  ,855°"5  laama^  that  the  developer  ^nay  wish 
suppoTe™  ronmem.8  89e"CV  ,0r  SUPPOr,ina  ,he  Oeliverable  software  and  associated 

,  ™«  58ction  5,1811  118  divided  in,°  Paragraphs  as  appropriate  to  describe  the 

section  shall7dt.de:  t,am'n0  SUP0Ort  perso,lnel  10  supP°r1  of  the  deliverable  software.  This 

a.  The  schedule,  duration,  and  location  for  the  training 

b.  The  delineation  between  classroom  training  and  "hands-on"  training 

c.  Provision  (either  directly  or  by  reference)  for: 

1 )  Familiarization  with  the  operational  software  and  target  computer(s) 

2)  Familiarization  with  the  support  software  and  host  system 

die  ^tab?e?oftwari.rh,,nf'f-  ™S  S8C,i°n  Sha"  d8SC,ib8  8ntiCip8t8d  ar885  °f  to 

the  IhiS  SeC,ion  5,18,1  *»  d™ded  into  paragraphs  as  needed  to  describe 

section  sha7a5dPresT,he  I™"’  S0,^'e  t8  «•  “»«  89ency.  This 

a.  All  activities  to  be  performed  to  transition  the  deliverable  software  to  the  sunnort 
agency.  These  activities  may  include  planning/coordination  meetings-  preparation  of 

Che7k  °,0,,h  'r:;l“'he  5up'1°"  898"dK  P^ing. 

checkout  of  the  onZ  TT env,ronment'  Packaging,  shipment,  installation,  and 
checkout  of  the  operational  software;  and  training  of  support  personnel. 

b.  Roles  and  responsibilities  for  each  activity 
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10.  PREPARATION  INSTRUCTIONS  ~  10.2  Content  Requirements  (continued) 

'■  sr*  ”“sout  ,he  ,,ansition  activi,ies  and «“  •— w«ch 

d‘  and  for  conducting  the  transition  activities.  These  schedules 

and  milestones  shall  be  compatible  with  the  contract  master  schedule. 

6‘  envircvunent  ^  inSta"ation  and  checkout  of  deliverable  items  in  the  support 

dreSSj’i  7!?®  S0"  shaJ,c°ntain  fleneral  Information  that  aids  in  understanding  this 

alDhab^iLi  Kc^^f^  ,nformat,on'  denary,  rationale).  This  section  shall  include  an 
document  *nH  *  ?-9  °<  8  acronVrms'  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  any  terms  and  definitions  needed  to  understand  *is  document 

A.  Accsndixss.  Appendixes  may  be  used  to  provide  information  published  seoaratelv  for 
anopnl)!6"  kT  il*ik  document  maintenance  (e.g.,  charts,  classified  date!  As apSe  each 
have  heerf  3  h  w  erBnce^  *n  ma‘n  b°dy  of  the  document  where  the  data  would  normally 

AppendixesshalHto  ** 
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APPENDIX  G.  HARDWARE,  SOFTWARE,  AND  DOCUMENTATION 

REQUIREMENTS 


This  appendix  summarizes  the  anticipated  hardware,  software,  and  documentation 
requirements  necessary  to  deploy  MAES  to  the  ships,  integrate  it  into  the  “C”  school 
curriculum,  and  transition  life  cycle  support  for  it  to  NSWC  PHD.  This  matrix  should  be 
used  as  a  working  document  for  future  planning. 
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llillll 

ISiliii 

•  -  _ 

■wmm 

Hardware: 

Laptop  computers 

28 

2 

■■ 

6 

3  (note  1) 

43 

Carrying  cases 

28 

2 

6 

3  - 

43 

Surge  protectors 

28 

0 

1 

6 

0 

38 

Overhead  projector 

0 

0 

U 

2 

0 

2 

Software: 

Prebundled  software 

28 

2 

4 

6 

3 

43 

MAES  runtime  version 

56(note  2) 

4 

8 

12 

6 

86 

MAES  development  version 

0 

1 

0 

0 

0 

1 

Documentation: 

Hardware  User’s  Manual 

28 

2 

4 

6 

3 

43 

Prebundled  SAV  User’s 

28 

2 

4 

6 

3 

43 

Manuals 

0 

2 

2 

2 

0 

6 

Knowledge  Documentation 

28 

4 

4 

6 

3 

45 

MAES  User’s  Manual 

0 

1 

0 

0 

0 

1 

System  Level  Description 

0 

1 

0 

0 

0 

1 

Software  Design  Document 

0 

1 

0 

0 

0 

1 

Version  Description  Document 

0 

1 

2 

0 

0 

3 

MAES  Deployment  Plan 

0 

1 

0 

2 

0 

3 

(Ships) 

0 

3 

0 

0 

0 

3 

MAES  Integration  Plan  (FTCs) 
MAES  Software  Transition 

Plan 

Table  G-l.  MAES  HAV,  SAV,  and  Documentation  Requirements  Matrix 

Note  1 .  One  laptop  would  go  to  the  NAVSEA  MK  92  Program  Manager  and  the  other 
two  would  go  to  each  of  the  type  commanders’  staffs. 


Note  2.  Two  copies  of  the  MAES  software  should  be  provided  to  each  activity.  One 
copy  should  remain  with  the  users  and  the  other  copy  should  be  transferred  to  the 
activity’s  ADP  officer  or  software  librarian. 
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